From: Mike Barnard on
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.
From: Alan Gutierrez on
Mike Barnard wrote:

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

--
Alan Gutierrez - alan(a)blogometer.com - http://twitter.com/bigeasy
From: Andreas Leitgeb on
Mike Barnard <m.barnard.trousers(a)thunderin.co.uk> wrote:
> 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.

From: Tom Anderson on
On Mon, 26 Jul 2010, Mike Barnard wrote:

> 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

--
Vive la chimie, en particulier, et la connaissance en general. --
Herve This
From: ClassCastException on
On Mon, 26 Jul 2010 01:37:38 -0500, Alan Gutierrez wrote:

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