Re: [take25 1/6] kevent: Description.

From: Ulrich Drepper
Date: Fri Nov 24 2006 - 11:12:20 EST


Evgeniy Polyakov wrote:
I know this is how it's done now. But it is not where it has to end. IMO we have to get to a solution where new events are posted to the ring buffer asynchronously, i.e., without a thread calling kevent_wait. And then you need the extra parameter and verification. Even if it's today not needed we have to future-proof the interface since it cannot be changed once in use.

There is a special flag in kevent_user to wake it if there are no ready
events - kernel thread which has added new events will set it and thus
subsequent kevent_wait() will return with updated indexes - userspace
must check indexes after kevent_wait().

You misunderstand. I don't want to return without waiting unconditionally.

There is a race which has to be closed. It's exactly the same as in the futex syscall. I've shown the interaction between the kernel and the thread in the previous mail. There is inevitably a time difference between the thread checking whether the ring buffer is empty and the kernel putting the thread to sleep in the kevent_wait call.

This is no problem with the current kevent_wait implementation since the ring buffer is not filled asynchronously. But if/when it will be the kernel might add something to the ring buffer _after_ the thread checks for an empty ring buffer and _before_ it enters the kernel in the kevent_wait syscall.

The kevent_wait syscall will only wake the thread when a new event is posted. We do not in general want it to be woken when the ring buffer is non empty. This would create far too many unnecessary wakeups it there is more than one thread working on the queue.

With the addition parameters for kevent_wait indicating when the calling thread last checked the ring buffer the kernel can find out whether the decision to call kevent_wait was made based on outdated information or not. Outdated in the case a new event has been posted. In this case the thread is not put to sleep but instead returns.

--
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/