title: Threads, Signals and Child Handling: What a world...What a world
body: <p>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. </p>
  
  <p>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 <code>sigwait()</code> 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. </p>
  
  <p>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. </p>
  
  <p>So as for my questions:</p>
  
  <ol>
  <li>Am I crazy about SIGCHLD not making it to my signal handler thread?</li>
  <li>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 <em>seems</em> to work, however I can't help think either I'm missing something OR there is a better way to <em>handle</em> this...he he, get it, <em>handle</em> this...okay I'll stop now</li>
  </ol>
  
  <p><code>As per David Schwartz request SLES9: NPTL 2.3.5, SLES10: NPTL2.4</code></p>