Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Tue, 22 Feb 2000 12:16:22 +0000 (GMT) | Subject | Re: accept() improvements for rt signals |
| |
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/
| |