Signals

Signals must be dealt with carefully in multithreaded applications. For a multithreaded application to avoid deadlocks when asynchronous events occur, the application's signal handlers must call only functions that do not request locks that may already be held by the same thread. The following programming rules will achieve this result:

1. A multithreaded application should create one or more separate signal-managing threads to wait synchronously (using sigwait(2)) for any signals of interest.

2. The signals of interest should be masked by all threads that call networking library routines, either from application code or from library code.

3. A signal-managing thread may call any networking library function.

SIGPOLL and SIGPIPE

In a single-threaded application, signals may just be ignored, but individual threads in a multithreaded application should not asynchronously change the process-wide disposition of a signal. In multithreaded applications, therefore, the XTI library and the Sockets Library block SIGPOLL and SIGPIPE in each thread that is performing certain operations, rather than ignore these signals at the process level. For this reason, multithreaded applications must either ignore SIGPOLL and SIGPIPE at the process level, or provide signal handlers for them. The default disposition for SIGPOLL is to ignore it, so you may need to take no special action to protect your application from spurious SIGPOLLs. However, the default disposition for SIGPIPE is to kill the process, so if your multithreaded application is calling the Sockets Library function rcmd(3N), then you should provide a handler for SIGPIPE.