Alan Cox wrote:
> > > kqueue currently does this; a close() on an fd will remove any pending
> > > events from the queues that they are on which correspond to that fd.
> >
> > the application of a close event. What can I say, "the fd formerly known
> > as X" is now gone? It would be incorrect to say that "fd X was closed",
> > since X no longer refers to anything, and the application may have reused
> > that fd for another file.
>
> 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.
(I suspect it helps that kevent() is both the only way to
bind events and the only way to pick them up; makes it harder
for one thread to sneak a new fd into the event list without
the thread calling kevent() noticing.)
- 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/
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:21 EST