On Saturday 29 July 2006 18:18, Ulrich Drepper wrote:

Evgeniy Polyakov wrote:

quoted

Btw, why do we want mapped ring of ready events?
If user requestd some event, he definitely wants to get them back when
they are ready, and not to check and then get them?
Could you please explain more on this issue?

If of course makes no sense to enter the kernel to actually get the
event.  This should be done by storing the event in the ring buffer.
I.e., there are two ways to get an event:

- with a syscall.  This can report as many events at once as the caller
  provides space for.  And no event which is reported in the run buffer
  should be reported this way

- if there is space, report it in the ring buffer.  Yes, the buffer
  can be optional, then all events are reported by the system call.


So the use case would be like this:


wait_and_get_event:

  is buffer empty ?

    yes -> make syscall

    no -> get event from buffer


To avoid races, the syscall needs to take a parameter indicating the
last event checked out from the buffer.  If in the meantime the kernel
put another event in the buffer the syscall immediately returns.
Similar to what we do in the futex syscall.

Couldn't this be done in a general way: Given a fd that supports streaming 
input, map some user-mem as a ring buffer for input. Maybe the kernel should 
control the buffer in order to make resizing possible (i.e., TCP zero-copy 
and window scaling).

Hans Henrik