Question on catching SIGCHLD in 2.6
This is probably something simple but I can't seem to figure it out.
I am helping an applications group that has been porting a program from 2.4 to 2.6. All that they know is that it revolves around a child process dying and the SIGCHLD gets sent to the wrong thread and sticks there.
While looking at this problem, I have modelled a test that starts, spins off 4 threads, forks/execs a second process that brings up four threads. I have written the first process capable of establishing signal handling on ANY one of the threads at a time. The second app, the threads come up, calculate a random sleep time from 10 to 25 seconds, and when each wakes up it terminates, when the last one terminates, the 2nd process dies.(They wanted to see it done this way to observe thread death and process death!)
Anyway, here is the SIMPLE explanation of what I see.
If I tell the first process to handle signals on ANY of the SPUN off threads, everything works fine! When the last thread dies, the second process croaks, and I see the SIGCHLD back in the signal handling thread in the first process. I then hit CTRL-C(SIGINT, which I am also watching for...) and the first process dies.
IF I tell the program to handle signals on the initial thread, I can see it set up the same mask, I can see it pass the exact same mask to sigwait(), and yet, when the second process dies, I see nothing in the signal handling in the first process. Nothing. The funny thing is, when I hit the CTRL-C the initial thread sees it, wakes up and announces it, and then dies like I tell it to.
It seems as though, for some reason, the initial thread is ignoring the SIGCHLD when I have not told it to but it is NOT ignored when I set up signal handling with the same procedure on a thread that I spun off.
Can anyone point me in a direction just BEFORE applying a swift kick? That way the momentum might help me get where I need to be!!!
Thanks!
Bob Ruth
|