"This method blocks until..." means what exactly?
in [Java Programming]
|
Prev: Process ID in Windows the best way
Next: JBR , RENT TO OWN or BUY WITH NO MONEY DOWN ,050-8320722
From: ClassCastException on 26 Jul 2010 22:43 On Mon, 26 Jul 2010 13:05:47 +0100, Tom Anderson wrote: > 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. 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.
From: Alan Gutierrez on 26 Jul 2010 23:30 ClassCastException wrote: > 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. 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. -- Alan Gutierrez - alan(a)blogometer.com - http://twitter.com/bigeasy
From: ClassCastException on 27 Jul 2010 23:07 On Mon, 26 Jul 2010 22:30:09 -0500, Alan Gutierrez wrote: > ClassCastException wrote: >> 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. > > 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.
From: Esmond Pitt on 28 Jul 2010 02:24 On 27/07/2010 12:43 PM, ClassCastException wrote: > 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.
From: Mike Barnard on 28 Jul 2010 17:35
On Mon, 26 Jul 2010 07:27:35 +0100, Mike Barnard <m.barnard.trousers(a)thunderin.co.uk> 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? > >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! |