All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maciek Borzecki <maciek.borzecki@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: pselect semantics - no EINTR with pending signals
Date: Fri, 9 Sep 2011 15:25:50 +0200	[thread overview]
Message-ID: <CALGyLaiXhtceaJxni9ttjMfzx6K326_CVccJiifAhXfNszdgsg@mail.gmail.com> (raw)

I'm running a deamon application, which listens on a number of
sockets, and occasionally spawns gzip to compress some data. It does
happen so, that pselect is used for mutliplexing IO. It also doest
happen so that on one of the fds there is always data to be read (just
a peculiarity of the application, a lot of clients are constantly
writing to a datagram socket and once the daemon is started there is
always data to be read).
That's more less how the code goes:
int main(..)
{
    sigset_t blockset;
    sigset_t oldset;
    ...
    signal(SIGCHLD, ...);
    sigemptyset(&blockset);
    sigaddset(&blockset, SIGCHLD);
    sigprocmask(SIG_SETMASK, &blockset, &oldset);
    ...

    while (1)
    {
        int ret = pselect(maxfd, fdset, NULL, NULL, NULL, &oldset);
        /* ret is always > 0 */

        {
            sigset_t pendset;
            sigpending(&pendset);
            /* apparenty SIGCHLD is present in pending set */
        }
    }
}

What happens is that once a child is spawned, and exists emitting a
SIGCHLD, the signal remains in the pending set. It can only be
determined that the signal was raised by looking at the pending mask.
It is also the case, that SIGCHLD is present in pending set before
entering pselect at some point. However none of the signal handlers
are called.
I looked 2.6.39 do_pselect and it seems that the signal handlers would
only be delivered once core_sys_select returns ERESTARTNOHAND, however
since there is always something to be read on the fds, core_sys_select
always returns value > 0. In that case set_restore_sigmask is never
called, and TIF_SIGPENDING is never set.
So it seems that there is no chance of having the signals delivered
unless pselect blocks waiting for I/O

Now, I'm not sure about the semantics of pselect. I'm not saying that
the current version is right or wrong, but raising a question if this
is really expected (and it did happen to be quite unexpected for me).

--
Maciek Borzecki

             reply	other threads:[~2011-09-09 13:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-09 13:25 Maciek Borzecki [this message]
2011-09-11 14:45 ` pselect semantics - no EINTR with pending signals Ulrich Drepper
2011-09-12  8:47   ` Maciek Borzecki

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=CALGyLaiXhtceaJxni9ttjMfzx6K326_CVccJiifAhXfNszdgsg@mail.gmail.com \
    --to=maciek.borzecki@gmail.com \
    --cc=linux-kernel@vger.kernel.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.