lkml.org 
[lkml]   [2008]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRationale for paccept() sigset argument?
From
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



\
 
 \ /
  Last update: 2008-08-20 18:57    [W:0.870 / U:1.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site