Rationale for paccept() sigset argument?

Rationale for paccept() sigset argument?

[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

Re: Rationale for paccept() sigset argument?

[Michael Kerrisk]

Ulrich -- Ping!

On Wed, Aug 20, 2008 at 6:50 PM, Michael Kerrisk
<mtk.manpages@googlemail.com> wrote:
> 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
>
>



-- 
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

Re: Rationale for paccept() sigset argument?

[Ulrich Drepper]

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.

Re: Rationale for paccept() sigset argument?

[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

Re: Rationale for paccept() sigset argument?

[Michael Kerrisk]

Ulrich -- ping!

---------- Forwarded message ----------
From: Michael Kerrisk <mtk.manpages@googlemail.com>
Date: Sep 2, 2008 9:58 AM
Subject: Re: Rationale for paccept() sigset argument?
To: Ulrich Drepper <drepper@gmail.com>
Cc: Michael Kerrisk <mtk.manpages@googlemail.com>, Ulrich Drepper
<drepper@redhat.com>, Davide Libenzi <davidel@xmailserver.org>, lkml
<linux-kernel@vger.kernel.org>, Andrew Morton
<akpm@linux-foundation.org>, Jakub Jelinek <jakub@redhat.com>, Linus
Torvalds <torvalds@linux-foundation.org>


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

Re: Rationale for paccept() sigset argument?

[Michael Kerrisk]

[CC+=Roland]

On 9/2/08, Michael Kerrisk <mtk.manpages@googlemail.com> wrote:
> 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