Open System Services Programmer's Guide

Using Signals With the setjmp() and longjmp() Functions
Using the setjmp() and longjmp() functions can interfere with signal handling. The longjmp()
function causes a thread to jump to the execution context saved by a previous call to the setjmp()
function, but it does not restore the signal mask of the process. If the longjmp() function is called
within a signal handler, the signal mask used in the signal handler is retained when execution
resumes at the setjmp() location. The exception mechanism uses the setjmp() and longjmp()
functions and behaves similarly.
The sigsetjmp() and siglongjmp() functions have an option to save and restore the signal
mask. This option can cause signals that were enabled by another thread to be inadvertently
masked.
When handling signals:
• Do not use the raise() function for an exception, and do not use the longjmp() function
to exit a synchronous signal handler. Simply returning from a signal handler is safe and is the
recommended practice.
• Use exception handlers instead of the setjmp() and longjmp() functions for threaded
OSS applications.
• Do not use the option of the sigsetjmp() and siglongjmp() functions that saves and
restores the signal mask. Doing so can cause signals enabled by another thread to be masked.
Thread-Aware Signal Handling
The PUT Model library catches both externally generated OSS signals and synchronous signals,
which are result of an event that occurs inside a process, and deliver them to the correct thread.
By default, thread-aware signal behavior is enabled.
388 Using the POSIX User Thread (PUT) Model Library