[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.078 / U:2.528 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site