Messages in this thread |  | | From | Dan Kegel <> | Subject | Re: kqueue microbenchmark results |
| |
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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |