Re: Unifying epoll,aio,futexes etc. (What I really want from epoll)

[Jamie Lokier <lk@tantalophile.demon.co.uk>]

John Gardiner Myers wrote:
> The cost of removing and readding the listener to the file's wait queue 
> is part of what epoll is amortizing.

Not really.  The main point of epoll is to ensure O(1) processing time
per event - one list add and removal doesn't affect that.  It has a
constant time overhead, which I expect is rather small - but Davide
says he's measuring that so we'll see.

> There's also the oddity that I noticed this week: pipes don't report 
> POLLOUT readiness through the classic poll interface until the pipe's 
> buffer is completely empty.  Changing this to report POLLOUT readiness 
> when the pipe's buffer is not full apparently causes NIS to break.

There's a section in the Glibc manual which talks about pipe
atomicity.  A pipe must guarantee that a write of PIPE_BUF bytes or
less either blocks or is accepted whole.  So you can't report POLLOUT
just because there is room in the pipe - there must be PIPE_BUF room.

Furthermore, the manual says that after writing PIPE_BUF bytes,
further writes will block until some bytes are read.  This latter does
not seem a useful requirement to me - I think that a pipe could be
larger than the PIPE_BUF atomicity value, but perhaps it is defined in
POSIX or SUS to be like this.  (Someone care to check?)

Together these would seem to imply the behaviour noted by John.

-- Jamie