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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:57 EST