Benjamin LaHaise wrote:

>If you look at how /dev/epoll does it, the collapsing of readiness 
>events is very elegant: a given fd is only allowed to report a change 
>in its state once per run through the event loop.
>
And the way /dev/epoll does it has a key flaw: it only works with single 
threaded callers.  If you have multiple threads simultaneously trying to 
get events, then race conditions abound.

>The ioctl that swaps 
>event buffers acts as a barrier between the two possible reports.
>
Which assumes there are only single threaded callers.  To work correctly 
with multithreaded callers, there needs to be a more explicit mechanism 
for a caller to indicate it has completed handling an event and wants to 
rearm its interest.

There are also additional interactions with cancellation.  How does the 
cancellation interface report and handle the case where an associated 
event is being delivered or handled by another thread?  What happens 
when that thread then tries to rearm the canceled interest?

I certainly hope /dev/epoll itself doesn't get accepted into the kernel, 
the interface is error prone.  Registering interest in a condition when 
the condition is already true should immediately generate an event, the 
epoll interface did not do that last time I saw it discussed.  This 
deficiency in the interface requires callers to include more complex 
workaround code and is likely to result in subtle, hard to diagnose bugs.