"This method blocks until..." means what exactly?

[Mike Barnard]

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?

Mike. Total newbie, struggling a bit.

 

[Alan Gutierrez]

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?

Better to think of it as waiting for a `byte` to become available,
rather than thinking of it as waiting for a `byte` to be found. If
you're reading from System.in, you would indeed block until the user hit
the keyboard. If you were reading from the network, you would block
until data from the network arrived.

If you're reading from a file, you'll block until the information is
available in memory for you to read, but that should happen so quickly,
you generally won't perceive a wait.

In the case of a command line or web application, I rarely sweat the
blocking of a network read. So, don't go thinking that you *must* spawn
a worker thread to slurp in a file, or pull down a web page.

 

[Andreas Leitgeb]

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?

Your best guess is good

In practice it means, that if your app's job is to read and process
input, and to just idle until more input becomes available, then you
don't have to care for the idling. The method will do the idling for
your app, until either input becomes available, or the stream is closed
from the other side.

 

[Tom Anderson]

Reading the documenation for InputStream methods shows this phrase used
a lot. Whats its definition?

'Block' just means 'doesn't return'. So if a method blocks until input is
available, then it doesn't return until input is available. As opposed to
returning straight away with some kind of 'no input is available'
indication.

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()?
Yes.

And if like me, one does not have an application with multiple threads
it will hang?

Yes. Until some input arrives.

tom

 

[ClassCastException]

In the case of a command line or web application, I rarely sweat the
blocking of a network read. So, don't go thinking that you *must* spawn
a worker thread to slurp in a file, or pull down a web page.

You may want to display a progress indicator or at least a throbber to
indicate that the thing's not dead. A command line throbber will need a
separate thread to keep it spinning. On the other hand, you can offload
animating a throbber to the client with a web app; either use some
Javascript or serve a page with a suitable animated gif. Of course this
should change to the browser's timeout error page if enough time passes
without a response.

 

[ClassCastException]

'Block' just means 'doesn't return'. So if a method blocks until input
is available, then it doesn't return until input is available. As
opposed to returning straight away with some kind of 'no input is
available' indication.

In practice, methods documented as blocking on some I/O event or monitor
usually also yield the CPU to other threads rather than chew up cycles
while blocking.

 

[Alan Gutierrez]

You may want to display a progress indicator or at least a throbber to
indicate that the thing's not dead. A command line throbber will need a
separate thread to keep it spinning.

I'm kind of imagining the OP saw the word "block" and thought, you mean
I need spawn a worker thread *every* time I read a file because it might
"block"? This was the kind if novice programmer I was, overdoing it
every step of the way. To that I say, local file system reads will
return so fast, it is not a long running tasks that needs to do
something to keep the user entertained.

So, yes, if you are going to build a general purpose command line Java
HTTP client, you would want to spawn a thread and run a throbber, but
there are plenty of times where I just count on, say the OAuth token
server, being there and being able to send me less than 1k in less time
that it takes to render a progress bar.

A decidedly worse is better approach, or cross that bridge when you come
it approach.

 

[ClassCastException]

I'm kind of imagining the OP saw the word "block" and thought, you mean
I need spawn a worker thread *every* time I read a file because it might
"block"? This was the kind if novice programmer I was, overdoing it
every step of the way. To that I say, local file system reads will
return so fast, it is not a long running tasks that needs to do
something to keep the user entertained.

So, yes, if you are going to build a general purpose command line Java
HTTP client, you would want to spawn a thread and run a throbber, but
there are plenty of times where I just count on, say the OAuth token
server, being there and being able to send me less than 1k in less time
that it takes to render a progress bar.

A decidedly worse is better approach, or cross that bridge when you come
it approach.

Mostly agreed, depending. Local file access is normally fast, though if
you're buffering gigs of data into RAM that qualifies as a "long running
task". OTOH network tasks where the remote host isn't reliably quickly
responsive need some sort of activity indicator IMO, and if the network
access MIGHT be via a non-broadband modem link then that goes for
everything.

I assume your OAuth token server example is some local-area-network
authentication doohickey that's normally fast and that has the property
that if it's ever down the user has way bigger problems than 1 app
becoming unresponsive, rather than some busy and popular Internet site
that people might still connect to at 56k and that's down every Tuesday
and alternate Friday and slow the rest of the time.

 

[Esmond Pitt]

In practice, methods documented as blocking on some I/O event or monitor
usually also yield the CPU to other threads rather than chew up cycles
while blocking.

And in theory. That's what 'block' means.

 

[Mike Barnard]

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?

Mike. Total newbie, struggling a bit.

A quick reply to all, just to say thanks. Reading documentation is
fine, understanding it however...

You'll hear more from me, no doubt!

 

[Arved Sandstrom]

That apparently depends who you ask. As I noted, "block" is normatively
used for these cases, but another poster to this thread defined it
basically as "does the job synchronously; does not return quickly while
another thread continues the task, or fail-fast if it can't do it right
away". The latter admits long-running computations and busy-waiting as
well as yielding at a monitor or similarly.

[ SNIP ]

A "blocking" function doesn't return until its work is completed.
Period. That's the only "in theory" associated with the term. A person
can invent a more specific definition for a given situation but then
they should be prepared to explain themselves.

AHS

 

[Screamin Lord Byron]

And in theory. That's what 'block' means.

We are mixing some different notions here which could be confusing for
the OP. Block means block, nothing else. If the method decides to chew
up CPU until it is finished it's still a blocking method if it doesn't
return immediately. That's all there is to it.

 

[Screamin Lord Byron]

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).

 

[ClassCastException]

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.

SwingWorker is a good example. It lets you turn a blocking operation
(such as I/O) into a non-blocking one suitable for calling from the Swing
event dispatch thread (EDT).

So if you have "readHugeFile();" in an action listener the EDT waits for
this (presumably blocking) IO operation and the UI becomes unresponsive.
But you can make a SwingWorker that implements its work method to call
readHugeFile() and store the resulting data structure in some instance
variable of your SwingWorker subclass and invoke the SwingWorker on the
EDT. The file is then loaded in some other thread. After that, the
SwingWorker's done() method is called on the EDT. You can implement the
done() method to do something, like display the data structure from the
ivar in a window.

Indeed this is how you would implement the File Open command in a multi-
document editor implemented with Swing where documents are often very
large objects. The Open command would produce a file selection dialog and
okaying rather than canceling this would trigger a SwingWorker to load
the document off the EDT whose done() method would spawn a new JFrame (or
JInternalFrame) to display the newly-opened document. While you were
waiting for your document to open though you could work on some other
open document or poke around in the Preferences or something.

(The remaining UI issue raised is the possibility that the newly opened
window will steal input focus while the user is working on something
else. If documents open quickly, you may just want to load them on the
EDT; if they sometimes load very slowly, though, it's best to let the
user keep working on others meanwhile, and then it's necessary to deal
with the possible focus swipe issue.)

 

[Esmond Pitt]

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.

 

[Arved Sandstrom]

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

 

[Nigel Wade]

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.

 

[Screamin Lord Byron]

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?

 

[Screamin Lord Byron]

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.

 

[Martin Gregorie]

Sure, but if you expect your code to be run only in a single thread
(like OP said) you probably wouldn't want that.

Depends whether there's a rendezvous and dispatch method that will block
until something of interest to the program happens.

Not having yet had any need to use the NIO classes I can only quote C
experience: a C server based round select() as the blocking rendezvous
can easily handle multiple clients without needing more than the single
main execution thread provided only that the actions triggered by an
event that causes select() to return are fast compared to the average
arrival rate of client requests. As a bonus, there are never locking
issues to deal with regardless of whether client sessions are stateless
or stateful: the only difference is that stateful sessions require
private storage for each session while stateless sessions, which usually
don't extend over more than a single transaction, don't need private
storage.

If the actions are slower than the average request arrival rate
(typically because at least some of the actions block), then and only
then there is a case for using multiple processing threads.