Re: [PATCH] rfc: threaded epoll_wait thundering herd

["Ulrich Drepper" <drepper@gmail.com>]

On 5/5/07, Davi Arnaut <davi@haxent.com.br> wrote:
> A google search turns up a few users. It also addresses some complaints
> from Drepper.

There is a huge problem with this approach and we're back at the
inadequate interface.

select/poll/epoll are thread cancellation points.  I.e., the thread
can be canceled before returning to the user.  If this cancellation
happens between the kernel deciding to give this thread the event (and
no other thread) and the thread testing for cancellation in the libc
wrapper around the syscall, then the event is lost and the process(es)
might hang.

With kevent we in the end fixed the problem by requiring that part of
the cancellation handling the thread tries to wake up another thread
waiting for the event queue.  This is easily possible since the event
data is in the shared memory segment and it's just purely the thread
wakeup that is needed.

To make something like this work for poll you'd have to push back the
revents fields of the result back to the kernel which might then cause
another thread to be woken up.  I find this too ugly to consider.  You
guys will not believe this but I really thought all these things
through before writing the OLS paper.  poll cannot be salvaged.


There is another thing about this selective wakeup: do I assume it
correctly that if more than one file descriptor is reported ready more
than one thread is woken?  I think nothing else can be justified.
Will in this case both threads get the same set of descriptors
reported or will they see disjunct sets?