On Mon, Oct 12, 2020 at 1:30 PM Michael Kerrisk (man-pages)
[off-list ref] wrote:
[CC += Davide]
I'm not sure how active Davide is any more..
I don't think this is correct. The epoll(7) manual page
sill carries the text written long ago by Davide Libenzi,
the creator of epoll:
Since even with edge-triggered epoll, multiple events can be gen‐
erated upon receipt of multiple chunks of data, the caller has the
option to specify the EPOLLONESHOT flag, to tell epoll to disable
the associated file descriptor after the receipt of an event with
epoll_wait(2).
My reading of that text is that in the scenario that I describe a
readiness notification should be generated at step 3 (and indeed
should be generated whenever additional data bleeds into the channel).
Hmm.
That is unfortunate, because it basically exposes an internal wait
queue implementation decision, not actual real semantics.
I suspect it's easy enough to "fix" the regression with the attached
patch. It's pretty nonsensical, but I guess there's not a lot of
downside - if the pipe wasn't empty, there normally shouldn't be any
non-epoll readers anyway.
I'm busy merging, mind testing this odd patch out? It is _entirely_
untested, but from the symptoms I think it's the obvious fix.
I did the same thing for the "reader starting out from a full pipe" case too.
Linus