Topics, signals and treatment of children: what kind of world ... What is the world

Question

So I have an interesting design problem. I am working on SLES 9+ Linux, the 2.6+ kernel, and have a multi-threaded application acting as an RPC client. The idea is to have multiple threads for processing requests; One such request is to run a “job” as a child process.

Now the problem is setting up the correct signal handler to work with various signals. What I did is set to a different thread to handle the signal sitting in sigwait() state, blocking all the corresponding signals in other threads. The idea is that all the signals for the process should be delivered to the signal processing stream, and the rest of the threads should only worry about processing the requests as they arrive.

All this works fine, except for those rotten children who always throw their freezes in my backyard and stomp all over my lawn ... but in all seriousness, my signal processing stream does not receive a SIGCHLD signal. My best guess about what is happening here is that since the signal stream is not a stream that spawns a child, it will not be the stream that receives SIGCHLD, but instead my workflows that did this.

Regarding my questions:

• Am I crazy about SIGCHLD not getting into the signal handler stream?
• If I'm not crazy (it's true, I know), how would you decide to fix this little problem? I am currently installing a very simple signal handler for SIGCHLD, configured for all threads, which simply passes the signal as a SIGUSR2 signal to a process group that is blocked in all threads, allowing the signal processing thread. It seems to work, but I can't help but think that I have something missing or there is a better way to handle it ... he, he realized, could handle it ... okay, I will stop now

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

Answer 1

(Edit: because I cannot read, and you are already making the correct pthread_sigmask calls ....)

In kernel 2.6, when SIGCHLD is set to ignore / SIG _IGN, the kernel will use child processes for you. It looks like if you configured a special handler for SIGCHLD for the signal processing flow to avoid setting SIGCHLD to SIG_IGN / SIG_DFL.

Edit (from comments): I think you hit the edge. If you leave it as SIG_IGN in the thread giving birth to children, the kernel will not even send SIGCHLD. But if you set it to handle, your handler is called instead. I think that if you install the handler, but then still block the signal in pthread_sigmask, the signal will be delivered to a stream that does not have a blocked signal (your sigwait stream).

Answer 2

Compile and run this code with approximately the same compilation options as for creating 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 entirely clear whether NPTL comes with SLES 9, and if so, if it is by default. But my bet is that you are using LinuxThreads, which does not have the ability to target the signal.