Hi,
On Mon, 21 Feb 2000 11:45:18 +0000 (GMT), Alan Cox
<alan@lxorguk.ukuu.org.uk> said:
> Im not sure about accept. Certainly for close() you want a queued notifier
> of the close completing to clean up the API edges
You need either a marker on close or on accept, but there's no need for
both.
With a marker on close, the process reading the siginfo stream simply
ignores all activity on that fd until after the corresponding SIGHUP is
received. We need to be 100% confident that there is one and only one
SIGHUP delivered per socket.
With a marker on accept, the closing thread flags the fd locally as
inactive, and the siginfo reader discards fd activity while the fd is
marked closed, or if it is open but the accept marker has not been seen
in the stream yet.
You can achieve this latter mode already with the existing API. You can
do an
accept()
F_SETSIG
F_SETOWN
F_ASYNC|O_NONBLOCK
sigqueue(pid, signo, fd) // Make sure the app resumes watching this fd
poll() // catch IO which arrived before going FASYNC
The sigqueue siginfo will be easily identified in the signal stream as
it will have a si_code of SI_QUEUE, not a poll reason.
Now, if you want to bundle all of the above into a single accept*() or
F_SETFAST syscall or fcntl, then we can do that. However, that's just a
matter of efficiency, not of correctness of the API.
Can anyone see any holes in this?
--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