[lkml]   [2000]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: kqueue microbenchmark results
    * David Schwartz <> [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

    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 - [|]
    "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
    Please read the FAQ at

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