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. > > 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.
See Linus's message on this same thread. > 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. Correct. > Will in this case both threads get the same set of descriptors > reported or will they see disjunct sets? Disjunct. In reality, only if the event is edge triggered. -- Davi Arnaut - 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/
