Messages in this thread | | | Date | Wed, 20 Aug 2008 18:50:12 +0200 | Subject | Rationale for paccept() sigset argument? | From | Michael Kerrisk <> |
| |
Ulrich,
I'll need to cover this point in the man pages, and the rationale still isn't clear to me, so I'll check it with you...
2.6.27-rc has paccept():
int paccept(int fd, struct sockaddr *sockaddr, socklen_t *addrlen, const sigset_t *sigmask, int setsize, int flags)
paccept() blocks until either a connection is received on fd, or a signal is sigmask() is caught.
What is the rationale for the sigset argument of paccept()?
For pselect()/ppoll()/epoll_pwait(), the sigset argument allows us to deal with a not uncommon situation: waiting for both signals and (multiple) file descriptors. (The alternative is the self-pipe trick, which requires more programming effort.)
However, do we really need this argument for paccept()? I ask this for the following reasons:
* This seems to be special casing for accept(). But there are other system calls (e.g., open(), connect(), recvfrom()) that are similar, in the sense that they may wait on a file descriptor, for which there is no [perceived need for a] sigset argument.
* It seems to me that any case where we might want to use paccept() could be equivalently dealt with using the existing pselect()/ppoll()/epoll_pwait() followed by a conventional accept() if the listening file descriptor indicates as ready. (But perhaps I missed something?)
Can you please explain why we need this special case for [p]accept()?
Cheers,
Michael
-- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
| |