"This method blocks until..." means what exactly?
in [Java Help]
|
Prev: Process ID in Windows the best way
Next: JBR , RENT TO OWN or BUY WITH NO MONEY DOWN ,050-8320722
From: Esmond Pitt on 30 Jul 2010 03:51 On 29/07/2010 7:21 PM, Arved Sandstrom wrote: > A "blocking" function doesn't return until its work is completed. > Period. But *all* functions have that characteristic (except for specifically designated async functions that generally post results via callbacks). It's just not a useful definition. You can't usefully regard 'still running' or 'hasn't returned yet' as 'blocking'. 'Blocked' generally means waiting for something *else*, e.g. in this case waiting for the kernel or the network to deliver some data.
From: Arved Sandstrom on 30 Jul 2010 05:40 Esmond Pitt wrote: > On 29/07/2010 7:21 PM, Arved Sandstrom wrote: >> A "blocking" function doesn't return until its work is completed. >> Period. > > But *all* functions have that characteristic (except for specifically > designated async functions that generally post results via callbacks). > It's just not a useful definition. You can't usefully regard 'still > running' or 'hasn't returned yet' as 'blocking'. 'Blocked' generally > means waiting for something *else*, e.g. in this case waiting for the > kernel or the network to deliver some data. As general as it may be, it's actually still a useful definition, because we invariably use it only for those functions where there can be a significant delay before the work associated with the function completes. You _could_ use the term for a function that adds two integers, but nobody would bother, it serves no purpose. So the way you phrased it in your last sentence is usually *when* and *where* we tend to use this general definition. It doesn't change the fact that it's a general definition. AHS -- Give a man a fish, and he can eat for a day. But teach a man how to fish, and he'll be dead of mercury poisoning inside of three years. --Charles Haas
From: Nigel Wade on 30 Jul 2010 06:20 On 30/07/10 10:40, Arved Sandstrom wrote: > Esmond Pitt wrote: >> On 29/07/2010 7:21 PM, Arved Sandstrom wrote: >>> A "blocking" function doesn't return until its work is completed. >>> Period. >> >> But *all* functions have that characteristic (except for specifically >> designated async functions that generally post results via callbacks). >> It's just not a useful definition. You can't usefully regard 'still >> running' or 'hasn't returned yet' as 'blocking'. 'Blocked' generally >> means waiting for something *else*, e.g. in this case waiting for the >> kernel or the network to deliver some data. > > As general as it may be, it's actually still a useful definition, > because we invariably use it only for those functions where there can be > a significant delay before the work associated with the function > completes. You _could_ use the term for a function that adds two > integers, but nobody would bother, it serves no purpose. > > So the way you phrased it in your last sentence is usually *when* and > *where* we tend to use this general definition. It doesn't change the > fact that it's a general definition. > > AHS > 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. -- Nigel Wade
From: Screamin Lord Byron on 30 Jul 2010 15:38 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?
From: Screamin Lord Byron on 30 Jul 2010 15:51
On 30.07.2010 05:34, ClassCastException wrote: > On Thu, 29 Jul 2010 12:17:45 +0200, Screamin Lord Byron wrote: > >> On 07/26/2010 08:27 AM, Mike Barnard wrote: >>> Hi. >>> >>> Reading the documenation for InputStream methods shows this phrase used >>> a lot. Whats its definition? >>> >>> My best guess is, in the case of read(), that the thread the call is in >>> will hang up until a chatacter is found by read()? And if like me, one >>> does not have an application with multiple threads it will hang? >> >> That's right. And if some method was defined as a non-blocking method, >> then it would return immediately (with no actual result of it's work) >> allowing your app to continue. Of course, you would have to check for >> the result later (with some other method). > > Actually, it's quite a common pattern to register some kind of callback > to be invoked automatically when the result is ready. Sure, but if you expect your code to be run only in a single thread (like OP said) you probably wouldn't want that. |