Hi,
On Sun, 20 Feb 2000 09:16:22 -0800, Dan Kegel <dank@alumni.caltech.edu>
said:
> Here's another possible race:
> User closes fd 5. Events for fd 5 are still in the signal queue.
> User does accept(), which returns a new fd 5.
You should be able to spot the close in the signal queue by looking for
the POLLHUP --- it would be relatively simple to add a POLLHUP on local
socket close (you should already get one on remote close). Without
that, the very worst that can happen is a wasted syscall as you read on
a file descriptor which isn't ready for read.
> That "fd 5 created" signal would tell the user code to reset its
> "fd 5 poll status" variable, which would then be updated by the sigio
> signals whenever fd 5's poll status changed. No need for an initial
> call to poll() or a poll struct * in F_SETFAST then.
No, but there's one extra signal delivered. You are just moving the
cost somewhere else, it's not really going to be significantly more
efficient than just doing the F_SETFAST poll return.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:30 EST