Re: Does Linux select() violate POSIX?

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> > We dont care, since every sane application using select() should also
> > use socket in non blocking mode.
> 
> This is simply not true for any POSIX-compliant operating system.
> Which in this case happens to include every Unix ever written since
> the beginning of time, apart from Linux.

Actually no - there are lots of device cases where instantaneously it is
true that a read would not block but the condition then changes again.

An obvious simple example beyond that is a socket with two readers.

> Put another way...  The whole point of the POSIX spec is to allow me
> to write portable code.  If every random Unix implementation makes up
> its own mind about what is "sane" and violates the spec in arbitrary
> and unpredictable ways, what is the point of having a spec?

Linux follows Posix generally, but nobody writes portable code that does
blocking reads on a poll/select interface because there are a bazillion
ways it can then block - events read by other tasks, discards due to
memory exhaustion, events that are cleared the other end, etc.

> > Between time select()/poll() says 'OK you can go', and time you enter
> > kernel, conditions might have changed. For example, maybe kernel memory
> > is not available and a send() would _block_, even if socket queue is
> > empty.
> 
> Sounds like a kernel bug.

It's a design decision and a huge performance win. It's one of the areas
where POSIX read in its strictest form cripples your performance.

Alan