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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
