Re: "This method blocks until..." means what exactly?
On Tue, 3 Aug 2010, Arved Sandstrom wrote:
Tom Anderson wrote:
On Mon, 2 Aug 2010, Arved Sandstrom wrote:
Nigel Wade wrote:
On 30/07/10 20:38, Screamin Lord Byron wrote:
On 30.07.2010 12:20, Nigel Wade wrote:
I infer "blocking" to imply:
a) no useful work is being performed
b) the duration is indeterminate (usually due to external factors)
whether it yields the CPU to other threads, or spins, isn't material to
the meaning of "blocked" - it may do either.
Wouldn't you say that a function which does some time consuming
cryptographic computation (like generating long RSA keypairs) blocks if
it doesn't return before the computation is finished?
No, I wouldn't.
To me, if it's actually performing its allotted task then it's running,
not blocked. If it were blocked then it would be doing nothing, unable to
perform it's required task (generally because it's waiting for some event
to occur). That's why the term "blocked" is used (similar to when a road
is blocked), it can't perform its function because something is
preventing it. If it's running, doing what it's meant to do, I would not
consider it blocked.
Yeah, but that's to "you". The general definition is simply that a
blocking (synchronous) method does not return until it has finished its
work, or it fails. That's it.
Evidence for this assertion, please.
I'm more or less with Nigel. I'm not bothered about whether the CPU is
busy, or whether useful work is being done, but to me, blocking means that
a method doesn't return *until some external actor causes it to*. The
long-running cryptographic function is not blocking, because it doesn't
require any external input to finish. A normal IO method is, because it can
get stuck waiting for hardware.
It seems to me that if you call the cryptographic function blocking, then
you have to call every function blocking, because no function returns
before the computations it performs are finished (although i understand
there's a Clojure extension for time-travel). That seems like a remarkably
useless definition of the term.
Evidence for the assertion? A great deal of Googling is what it came
down to, on various combinations of "method", "I/O", "blocking", "block"
and "blocked". I left out "thread" and "threading" entirely, so as not
to confuse the results. I also filtered or weighted based on whether the
context of the discussion was a newish language (Ruby, Java etc) or
something like C; I also included definitions from discussions about
"remote" calls (newish or not: RMI, CORBA, web services etc).
My intention with this searching was to establish a common ground. It's
not perfect; a better but considerably more time-consuming approach
would be to go pre-World Wide Web and consult printed sources. I did
however try to capture sources that were either older, or seemed to be
older in "mindset".
And that's the best definition I arrived at: that a blocking method does
not return until its mission is accomplished. As you know the term is
commonly used in the I/O context and in this case we *are* talking about
the I/O context. Within this context simply defining it the way a lot of
sources use it, as a method that does not return until it succeeds in
doing its work, or it fails, _is_ useful.
Yes, that's true. But in that context, i'm not sure how you could
distinguish our definitions!
I was originally addressing the idea that the definition involved what
the method was doing while it waited (if it waited), and I'm simply
saying that for I/O blocking methods that the useful definition doesn't
care. In fact you've stated so yourself.
You're right, we're in violent agreement here.
I don't however think there's any need to garnish the definition with
mention of external actors, which is where we may differ. It's an I/O
method - draw your own conclusions.
I will dispute however that one cannot use the terminology for non-I/O
methods.
Evidently!
If we are discussing potentially long-running computations of any kind,
then we can have both synchronous (blocking) computations and
asynchronous (non-blocking *) computations. This terminology is common.
It seems entirely alien to me.
Here's my half-arsed statistical contribution. I google for "the * method
is blocking" used as an indicative phrase, and present the first 21
distinct hits which are accessible without registration (ie not a paper
from behind a paywall). For each, i give the URL, the phrase containing
the hit given in the google snippet, and my interpretation of what it is
the method is blocking *until*.
http://www.cs.virginia.edu/~mngroup/hypercast/designdoc/API+Example/api.htm
"We note that the receive method is blocking"
-> arrival of a message from a network
http://blog.rguha.net/?p=651
"The receive method is blocking, so the program will wait for the next
message."
-> arrival of a JMS message on a queue
http://forums.java.net/jive/message.jspa?messageID=389765
"I found out that exactly the getResponseCode() method is blocking."
-> reception of a HTTP status-line
http://java.itags.org/java-core-gui-apis/61647/
"I know that the getNextEvent() method is blocking."
-> arrival of a GUI event
http://forums.sun.com/thread.jspa?threadID=431842
"Unfortunately the fireTimeChangeEvent method is blocking."
-> a called method has finished executing
http://www.interfaceware.com/manual/llp_service.html
"The RunMessageLoop method is blocking."
-> "a POST_QUIT message is sent to the networking thread"
http://hci.rwth-aachen.de/istuff/tutorial_eventheap.pdf
"The waitForEvent method is blocking"
-> "the expected event got posted."
http://blog.gmane.org/gmane.network.iperf.user/month 100501
"the sendto method is blocking at higher rates"
-> a buffer is drained to the network (i think)
http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/e5e1df1a-960d-43f5-9bf2-829478e7a9e8
"the Run() method is blocking the calling thread with the Join() method"
-> another thread terminates
http://docs.codehaus.org/display/GEOTDOC/Catalog
"the resolve method is blocking"
-> retrieval of data from "disk, remote service, etc"
http://code.google.com/p/jadss/wiki/ProjectArchitecture
"the write method is blocking"
-> a buffer is drained to the sound card
http://www.leighboxing.com/Boxing-Tips
"The most instinctive method is blocking"
-> er, until you see a chance to punch someone, i think
http://bytes.com/topic/c-sharp/answers/381461-xmlserialization-over-networkstream
"the Deserialize method is blocking."
-> a serialized string is received from the network
http://pocoproject.org/docs/Poco.AbstractEvent.html
"This method is blocking."
-> all registered delegates have been notified
http://www.mail-archive.com/android-beginners@googlegroups.com/msg10256.html
"in MODE_STEAMING the write method is blocking"
-> a sound clip has been played (i think)
http://www.codeproject.com/KB/directx/OdysseyUI.aspx
"In windows forms the MessageBox.Show method is "blocking"
-> "until the user presses one of the dialog's buttons"
http://www.zanshu.com/ebook/388_network_programming_for_microsoft_windows_-_second_edition/netprog2html/32ch16i.htm
"the Connect method is blocking"
-> "a connection [over the network] is made or an error is returned"
http://sw.nokia.com/id/59c97da0-92fb-4d85-8b7c-3e1b241a6b65/MIDP_Mobile_Media_API_Developers_Guide_v1_0_en.pdf
"the above method [Manager.createPlayer] is blocking"
-> "the media is loaded."
http://foxtrot.sourceforge.net/docs/worker.php
"The Worker.post() method is blocking"
-> "the time-consuming task is finished or throws an exception"
http://smsj.sourceforge.net/apidocs/org/marre/sms/transport/ucp/UcpTransport.html
"Depending on the implementation this method is blocking or non-blocking."
-> an SMS message has been sent "through an UCP SMSC" (i think)
http://www.j2meforums.com/forum/index.php?topic=22037.0
"The getResponse method is blocking"
-> "you receive a response from the server"
One of those is about boxing. Of the 20 that are about computers, the
methods block until:
- something is received from the network (6)
- a buffer drains to somewhere (3)
- some unspecified code finishes executing (3)
- a GUI event occurs (2)
- some unspecified kind of event is received (2)
- some unspecified kind of IO is complete (2)
- a JMS message is received (1)
- another thread terminates (1)
I consider any of the IO-based cases (6 + 3 + 2 = 11), any of the
event-based cases (2 + 2 = 4), the JMS case (1) and the thread termination
case (1) to be waiting for an external actor, for a total of 17. Three of
the cases are clearly about waiting for some arbitary code to complete.
You could quibble about the thread termination case, but then you could
quibble about whether the arbitrary code excludes that which indirectly
blocks on some external actor.
So, of this small sample, 15% could be talking about waiting for something
which may not involve an external actor. Of those, one is from C++, one is
from a newbie on a forum, and one is talking about time-consuming things
that happen behind a GUI, which very often *will* be dependent on some
external actor. I'm not really persuaded that use of the word "blocking"
to describe methods whose completion is not dependent on an external actor
is common.
tom
--
Dreams are not covered by any laws. They can be about anything. --
Cmdr Zorg