CODEWITHSUNDEEP
c++linuxmultithreadingsignals
Bob9630
Bob9630

Reputation: 953

Threads, Signals and Child Handling: What a world...What a world

So I have an interesting design problem. I am working on SLES 9+ Linux, kernel 2.6+, and have a multi-threaded application acting as an RPC client. The idea is to have few threads in place to process requests; one such request is to start a "job" as a child process.

Now the problem I'm having is setting up a proper signal handler to deal with a variety of signals. What I've done is set up a another thread for signal handling sitting a sigwait() state while blocking all relevant signals in the other threads. The idea is that all signals for the process should be delivered to the signal handling thread and the rest of the threads should worry only about processing requests as they come in.

All of this works great except for those rotten children, always throwing their Frisbees in my backyard and trampling all over my lawn...but in all seriousness, my signal handling thread is not getting the SIGCHLD signal. My best guess as to what is happening here is that because the signal handing thread is not the thread that spawned the child, it will not be the thread that receives SIGCHLD, but instead the my worker threads which did will.

So as for my questions:

  1. Am I crazy about SIGCHLD not making it to my signal handler thread?
  2. If I am not crazy (it's a stretch, I know), how would you go about fixing this little problem? Currently what I am doing is setting a very simple signal handler for SIGCHLD set up on all threads that simply resends the signal as a SIGUSR2 signal to the process group which is blocked in all threads allowing the signal handling thread. This seems to work, however I can't help think either I'm missing something OR there is a better way to handle this...he he, get it, handle this...okay I'll stop now

As per David Schwartz request SLES9: NPTL 2.3.5, SLES10: NPTL2.4

Upvotes: 6

Views: 1712

Answers (2)

SoapBox
SoapBox

Reputation: 20609

(Edit: Because I can't read and you are already doing proper pthread_sigmask calls....)

In the 2.6 kernel, when SIGCHLD is set to ignore/SIG_IGN the kernel will reap child processes for you. It sounds like if you set up a specific handler for SIGCHLD for your signal handling thread in order to avoid having SIGCHLD set to SIG_IGN/SIG_DFL.

Edit (from comments): I think you hit an edge case. If you leave it as SIG_IGN in the thread spawning the children, the kernel won't even send SIGCHLD. But if you set it to be handled, then your handler is called instead. I think if you set a handler but then still block the signal in pthread_sigmask, the signal will be delivered to a thread that doesn't have the signal blocked (your sigwait thread).

Upvotes: 2

David Schwartz
David Schwartz

Reputation: 182769

Compile and run this code with roughly the same compiling options as you use to build your program:

#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
int main(void)
{
    char buf[512];
    confstr(_CS_GNU_LIBPTHREAD_VERSION, buf, 500);
    printf("%s\n", buf);
}

This announcement is not quite clear on whether NPTL ships with SLES 9 and, if so, if it's the default. But my bet is that you are using LinuxThreads which does not have the ability to target a signal to a process.

Upvotes: 1

Related Questions