Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #1995 > unrolled thread

Combination of sigwait() with sigaction()?

Back to article view | Back to comp.programming.threads

Contents

  Combination of sigwait() with sigaction()? Markus Elfring <Markus.Elfring@web.de> - 2013-11-21 17:50 +0100
    Re: Combination of sigwait() with sigaction()? Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2013-11-21 17:02 +0000
      Re: Combination of sigwait() with sigaction()? Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2013-11-21 17:32 +0000
      Re: Combination of sigwait() with sigaction()? Markus Elfring <Markus.Elfring@web.de> - 2013-11-21 18:38 +0100
    Re: Combination of sigwait() with sigaction()? "Chris M. Thomasson" <no@spam.invalid> - 2013-11-21 14:52 -0800

#1995 — Combination of sigwait() with sigaction()?

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

[toc] | [next] | [standalone]

#1996

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.

[toc] | [prev] | [next] | [standalone]

#1998

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.

[toc] | [prev] | [next] | [standalone]

#1999

> 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

[toc] | [prev] | [next] | [standalone]

#2000

> "Markus Elfring"  wrote in message 
> news:bf6rviFm5kiU1@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

;^) 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web