All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Kerrisk <mtk.manpages@googlemail.com>
To: Ulrich Drepper <drepper@redhat.com>
Cc: Davide Libenzi <davidel@xmailserver.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: paccept() oddity
Date: Wed, 20 Aug 2008 18:50:54 +0200	[thread overview]
Message-ID: <48AC4B6E.4040409@gmail.com> (raw)

Ulrich,

[
2.6.27-rc has paccept():

int paccept(int fd, struct sockaddr *sockaddr, socklen_t *addrlen,
         const sigset_t *sigmask, int setsize, int flags)
]

While considering the sigset argument for paccept() (see my previous
message), and testing that system call, I realized that there is a certain
oddness in the implementation of paccept().

Like accept(), paccept() automatically restarts if interrupted by a signal
handler that was established with the SA_RESTART flag.

On the other hand, pselect(), ppoll(), and epoll_pwait() are never restarted
if interrupted by a handler, even if the handler was established with
SA_RESTART.  (This is the same as with select(), poll(), and epoll_wait().)

It seems to me that it makes little sense to restart paccept(), especially in
the case where it is interrupted by a handler for one of the signals that is
in sigmask, since the whole point of calling paccept() is to block until a
connection is received, or until one of the signals in sigmask is caught().

How about changing paccept() so that it is never automatically restarted if
interrupted by a signal handler, regardless of the SA_RESTART flag.  (In
other words, paccept() should be consistent with pselect(), ppoll(), and
epoll_pwait(), rather than being consistent with accept().)  What are your
thoughts?

Cheers,

Michael


             reply	other threads:[~2008-08-20 16:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-20 16:50 Michael Kerrisk [this message]
2008-08-29 20:45 ` paccept() oddity Michael Kerrisk
2008-09-08 13:31   ` Michael Kerrisk
2008-09-10 18:10 ` Andrew Morton
2008-09-11  0:38   ` Roland McGrath
2008-09-11  5:47     ` Michael Kerrisk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48AC4B6E.4040409@gmail.com \
    --to=mtk.manpages@googlemail.com \
    --cc=akpm@linux-foundation.org \
    --cc=davidel@xmailserver.org \
    --cc=drepper@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.