Messages in this thread | | | Date | Tue, 02 Sep 2008 09:58:09 +0200 | Subject | Re: Rationale for paccept() sigset argument? | From | Michael Kerrisk <> |
| |
Ulrich Drepper wrote: > On Wed, Aug 20, 2008 at 9:50 AM, Michael Kerrisk > <mtk.manpages@googlemail.com> wrote: >> What is the rationale for the sigset argument of paccept()? > > accept, like select/poll, is used often as a function to dealy > operation. Unlike read, recv, etc, which are handled using O_NONBLOCK > and select/poll. pselect/ppoll do not really have a sigset parameter > to handle signals in general. You use it to enable special handling > in case of blocking. Example: if you want to implement userlevel > context switching, you dedicate a signal to wake up any blocked > thread. Since accept falls more into the same category than poll, > this means the sigset parameter is justified. In theory we could add > it to all functions but there is no reason to do this without any > other reason to change the interface.
Ulrich, you snipped a relevant piece of my earlier message:
[[ > * 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. ]]
So I'll rephrase: what use case does the sigset argument of paccept() allow us to handle that couldn't equally have been handled by pselect()/ppoll()/epoll_pwait() + traditional 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
| |