On Mon, 7 May 2007, Ulrich Drepper wrote: > On 5/5/07, Davi Arnaut <[EMAIL PROTECTED]> 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.
So, by the same logic, every API that 1) returns something to userspace by canceling its internal kernel state 2) is not based on shared kernel/userspace memory, will break under your assumptions. Scary, because there's a pretty long list. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
