Alan Cox wrote:
> Im not sure about accept. Certainly for close() you want a queued notifier
> of the close completing to clean up the API edges
That would be good. It would make it easier to ignore stale events.
If the overall mantra of the F_SETSIG etc. api is "You never need
to call poll() except when the RT sig queue overflows", though,
we need to have events generated during the entire lifetime
of each socket fd. Currently, there's a gap between the
accept() and when rt signal generation is turned on for the fd,
so you need to do a poll() to see if data arrived on the socket
between accept() and F_SETSIG etc.
How harmonious it would be if you could be sure that there was
no gap. This would require either
* the new socket to inherit the F_SETSIG settings of the old
one (works for some cases, but makes some server designs hard)
or
* an atomic accept-and-F_SETSIG,FASYNC,F_SETOWN call (works for
all server designs I know of)
It would add some pleasing symmetry if the enhanced accept() also
generated a queued notifier. Then a thread watching a signal
queue would need *no other source of information* to learn that
it had been assigned an fd to serve, and to maintain its local
copy of the fd's poll state. Er, unless the queue overflowed,
I guess. Sigh.
- Dan
-
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:28 EST