Terry Lambert wrote:
>
> > > Which is precisely why you need to know where in the chain of events this
> > > happened. Otherwise if I see
> > > 'read on fd 5'
> > > 'read on fd 5'
> > > How do I know which read is for which fd in the multithreaded case
> >
> > That can't happen, can it? Let's say the following happens:
> > close(5)
> > accept() = 5
> > call kevent() and rebind fd 5
> > The 'close(5)' would remove the old fd 5 events. Therefore,
> > any fd 5 events you see returned from kevent are for the new fd 5.
>
> Strictly speaking, it can happen in two cases:
>
> 1) single acceptor thread, multiple worker threads
> 2) multiple anonymous "work to do" threads
>
> In both these cases, the incoming requests from a client are
> given to any thread, rather than a particular thread.
>
> In the first case, we can have (id:executer order:event):
>
> 1:1:open 5
> 2:2:read 5
> 3:4:read 5
> 2:3:close 5
>
> If thread 2 processes the close event before thread 3 processes
> the read event, then when thread 3 attempts procssing, it will
> fail.
You're not talking about kqueue() / kevent() here, are you?
With that interface, thread 2 would not see a close event;
instead, the other events for fd 5 would vanish from the queue.
If you were indeed talking about kqueue() / kevent(), please flesh
out the example a bit more, showing who calls kevent().
(A race that *can* happen is fd 5 could be closed by another
thread after a 'read 5' event is pulled from the event queue and
before it is processed, but that could happen with any
readiness notification API at all.)
- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
