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

[Ulrich Drepper]

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/