Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Newsgroups: comp.programming.threads,comp.unix.programmer
Subject: Re: Combination of sigwait() with sigaction()?
Date: Thu, 21 Nov 2013 17:32:13 +0000
Lines: 71
Message-ID: <87vbzl7jaa.fsf@sable.mobileactivedefense.com>
References: <bf6rviFm5kiU1@mid.individual.net> <87zjox7kn9.fsf@sable.mobileactivedefense.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: individual.net xXzzQf48m531qRgADNNYwAn5Y8wj4Ljbb14KEnIIu9M72IEwI=
Cancel-Lock: sha1:SikX3Yus620GMZjABEH3+spIJ5c= sha1:qwoZPyYOfpQmmxdpSyyMjeRBOdA=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
Xref: csiph.com comp.programming.threads:1998 comp.unix.programmer:5002

Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:

> Markus Elfring <Markus.Elfring@web.de> writes:
>> I have found an interesting article about waiting for signals in a separate
>> thread. A source code skeleton is shown.
>> http://devcry.heiho.net/2009/05/pthreads-and-unix-signals.html
>>
>> The author suggested also to install an empty signal handler by the function
>> "sigaction". How do you think about this suggestion?
>> Is the mentioned indication of non-default signal actions useful here?
>
> The author is somewhat confused here: sigwait returns "pending signals",
> this means "signals which don't cause any 'action' because they're
> blocked", hence, no "default actions" will happen. But the disposition
> of a signal can be set to something other than "default action" or "signal
> handler", namely, to "ignore this signals" and signals set to be ignored
> don't become pending signals, they're just discarded (and hence, sigwait
> will never return them). The main annoyance here is that the default
> disposition of SIGCHLD is "ignore", hence, without setting that to
> something else, sigwait (and similar routines) will never return a
> SIGCHLD.

SUS actually leaves this (immedidately discarding ignored signals)
unspecified and at least on the two systems where I tested this (running
Linux 3.2.9 and Linux 2.6.36.4), this program

----------
#include <signal.h>
#include <stdio.h>
#include <unistd.h>

static void child(void)
{
    sleep(1);
    fputs("\tchild going down\n", stderr);
    _exit(0);
}

static void dummy(int unused)
{}

int main(void)
{
    sigset_t wanted;
    int sig;

    sigemptyset(&wanted);
    sigaddset(&wanted, SIGINT);
    sigaddset(&wanted, SIGCHLD);
    sigprocmask(SIG_BLOCK, &wanted, NULL);

    if (fork() == 0) child();

    sigwait(&wanted, &sig);
    fprintf(stderr, "got signal %d\n", sig);

    signal(SIGCHLD, dummy);

    if (fork() == 0) child();

    sigwait(&wanted, &sig);
    fprintf(stderr, "got signal %d\n", sig);

    return 0;
}
------------

does indicate that a SIGCHLD was received in both cases. I remember
running into lost SIGCHLDs in the past, though, that's why I started to
install dummy handlers for everything I wanted to handle via
sigwaitsomething.