On Thu, Oct 08, 2009 at 12:17:38PM -0400, Gordon Molek wrote:
> We have an application where the main thread sets up a signal handling function for SIGTERM, spawns a secondary thread
 using pthread_create() and then calls pause() waiting for a SIGTERM to arrive.  The secondary thread will attempt to 
create an outgoing TCP connection (POP3), attempt to retrieve e-mails from the server, close the connection and then 
sleep for a specified interval before trying again.
> 
> The weird behavior is that if we give the invalid IP address of "0.0.0.0" everything works as expected, no e-mails are
 retrieved, but the application exits gracefully when a SIGTERM is sent to it.  However, if we have a valid IP address 
configured, the signal appears to cause the sleeping secondary thread to wake up, not the paused primary thread.  Is 
there some strange interaction between the sockets library and the signals handling code?  If so, how do we resolve this
?

There's nothing specific to sockets that would affect this.
You're probably just experiencing the signal delivery rules.
Signals sent to a process are delivered to the first thread
that doesn't have a signaled blocked.  Check out the signal
section of the ipc section of the system architecture guide.
You can direct a signal to a particular thread with judicious
use of pthread_sigmask().

-seanb

First, disable the signal for the main thread so that when you start child threads they inherit the signal mask with 
signal handling disabled and right before you are going to start waiting enable the signal back again.