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

Discussion in 'Java' started by Mike Barnard, Jul 26, 2010.

  1. Mike Barnard

    Mike Barnard Guest

    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.
    Mike Barnard, Jul 26, 2010
    #1
    1. Advertising

  2. 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 - - http://twitter.com/bigeasy
    Alan Gutierrez, Jul 26, 2010
    #2
    1. Advertising

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


    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.
    Andreas Leitgeb, Jul 26, 2010
    #3
  4. Mike Barnard

    Tom Anderson Guest

    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
    Tom Anderson, Jul 26, 2010
    #4
  5. 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.
    ClassCastException, Jul 27, 2010
    #5
  6. 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.
    ClassCastException, Jul 27, 2010
    #6
  7. 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 - - http://twitter.com/bigeasy
    Alan Gutierrez, Jul 27, 2010
    #7
  8. 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.
    ClassCastException, Jul 28, 2010
    #8
  9. Mike Barnard

    Esmond Pitt Guest

    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.
    Esmond Pitt, Jul 28, 2010
    #9
  10. Mike Barnard

    Mike Barnard Guest

    On Mon, 26 Jul 2010 07:27:35 +0100, 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?
    >
    >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!
    Mike Barnard, Jul 28, 2010
    #10
  11. ClassCastException wrote:
    > On Wed, 28 Jul 2010 16:24:11 +1000, Esmond Pitt wrote:
    >
    >> 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.

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

    --
    I'm not a vegetarian because I love animals. I'm a vegetarian because I
    hate plants.
    -- AW Brown
    Arved Sandstrom, Jul 29, 2010
    #11
  12. On 07/28/2010 08:24 AM, Esmond Pitt wrote:
    > 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.


    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, Jul 29, 2010
    #12
  13. 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).
    Screamin Lord Byron, Jul 29, 2010
    #13
  14. 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.

    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.)
    ClassCastException, Jul 30, 2010
    #14
  15. Mike Barnard

    Esmond Pitt Guest

    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.
    Esmond Pitt, Jul 30, 2010
    #15
  16. 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
    Arved Sandstrom, Jul 30, 2010
    #16
  17. Mike Barnard

    Nigel Wade Guest

    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
    Nigel Wade, Jul 30, 2010
    #17
  18. 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?
    Screamin Lord Byron, Jul 30, 2010
    #18
  19. 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.
    Screamin Lord Byron, Jul 30, 2010
    #19
  20. On Fri, 30 Jul 2010 21:51:13 +0200, Screamin Lord Byron wrote:

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


    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.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
    Martin Gregorie, Jul 31, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rookie
    Replies:
    4
    Views:
    14,748
    Chris Langsenkamp
    Aug 20, 2003
  2. clintonG

    Re: What means Protected WithEvents ?

    clintonG, Jul 5, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    422
    clintonG
    Jul 5, 2003
  3. news.microsoft.com
    Replies:
    1
    Views:
    1,218
    Justin Martin
    Aug 10, 2003
  4. Andreas Klemt
    Replies:
    2
    Views:
    328
  5. ronaldlee
    Replies:
    3
    Views:
    3,543
    Hans Kesting
    Dec 16, 2004
Loading...

Share This Page