Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Combination of sigwait() with sigaction()?

115 views
Skip to first unread message

Markus Elfring

unread,
Nov 21, 2013, 11:50:57 AM11/21/13
to
Hello,

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?

Regards,
Markus

Rainer Weikusat

unread,
Nov 21, 2013, 12:02:50 PM11/21/13
to
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.

Rainer Weikusat

unread,
Nov 21, 2013, 12:32:13 PM11/21/13
to
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.

Markus Elfring

unread,
Nov 21, 2013, 12:38:24 PM11/21/13
to
> 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.

Thanks for your feedback.

I have just found that the section "12.8 Threads and Signals" of the book
"Advanced Programming in the UNIX� Environment" contains also a bit of
information for the requested issue. The corresponding handling might be
implementation-defined. Is any more clarification for such details possible?

Regards,
Markus

Chris M. Thomasson

unread,
Nov 21, 2013, 5:52:18 PM11/21/13
to
> "Markus Elfring" wrote in message
> news:bf6rvi...@mid.individual.net...
> Hello,
> 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

> [...]

FWIW, check this crazy shi% out:

https://groups.google.com/d/topic/comp.programming.threads/lUXT4XgGzP4/discussion

;^)

0 new messages