lkml.org 
[lkml]   [2000]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: kqueue microbenchmark results
    * David Schwartz <davids@webmaster.com> [001025 15:35] wrote:
    >
    > If a programmer does not ever wish to block under any circumstances, it's
    > his obligation to communicate this desire to the implementation. Otherwise,
    > the implementation can block if it doesn't have data or an error available
    > at the instant 'read' is called, regardless of what it may have known or
    > done in the past. It's also just generally good programming practice. There
    > was a time when many operating systems had bugs that caused 'select loop'
    > type applications to hang if they didn't set all their descriptors
    > non-blocking.

    Yes, and as you mentioned, it was _bugs_ in the operating system
    that did this.

    I don't think it's wise to continue speculating on this issue unless
    you can point to a specific document that says that it's OK for
    this type of behavior to happen.

    Let's take a look at the FreeBSD manpage for poll:

    POLLIN Data other than high priority data may be read without
    blocking.

    ok no one bothers to do *BSD compat anymore (*grumble*),
    so, Solaris:

    POLLIN Data other than high priority data may be read
    without blocking. For STREAMS, this flag is set in
    revents even if the message is of zero length.

    I see a trend here, let's try Linux:

    #define POLLIN 0x0001 /* There is data to read */

    This seems to imply that it is one hell of a bug to block, returning
    an error would be acceptable, but surely not blocking.

    I know manpages are a poor source for references but you're the one
    putting up a big fight for blocking behavior from poll, perhaps you
    can point out a standard that contradicts the manpages?

    --
    -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
    "I have the heart of a child; I keep it in a jar on my desk."
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:45    [W:0.033 / U:60.316 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site