7b3
Subj : Re: sigwait() is not catching SIGUSR1 signal
To   : comp.programming.threads,comp.unix.programmer
From : David Butenhof
Date : Fri Mar 11 2005 01:48 pm

Neelakantan wrote:
>       
>      i have a problem with sigwait() in a multithreaded program. 
> 
>      In this program some thread will be generating the signal SIGUSR1 at 
>      some time(asynchronously) and there is a dedicated thread for handling 
>      the asynchronous(SIGUSR1 in my case) signals.
>  
>      The sinal handling thread uses sigwait() to catch the signal, however 
>      the signal is not caught by the sigwait() function. I have blocked the 
>      signal SIGUSR1 before the threads are created aswell before the sigwait() 
>      is called.

Your program looks OK... Although you should be checking the return 
status of sigwait(). Right now, if it were to fail, you'd go into an 
infinite hot loop.

I wonder if you could be running LinuxThreads? That might explain why it 
works when you use the kill(1) but not when the program uses kill(2). 
LinuxThreads was able to manage only a loose approximation of the POSIX 
process model; and one of the weakest areas was signal handling. In 
particular, there was no such thing as a "process pending signal mask"; 
a blocked signal would "stick" to the thread it hit first. When you 
kill(1) the "process", externally, it may hit the main thread (which is 
blocked in sigwait() and takes the signal as you expect), while the 
kill(2) from within a different thread delivers the signal to itself, 
finds it blocked, and pends against that thread... never reaching the 
main thread's sigwait(). NGPT, however, shouldn't have this problem, and 
I thought that was the default on Red Hat 9...

-- 
Dave Butenhof, David.Butenhof@hp.com
HP Utility Pricing software, POSIX thread consultant
Manageability Solutions Lab (MSL), Hewlett-Packard Company
110 Spit Brook Road, ZK2/3-Q18, Nashua, NH 03062

.

0