Problem - Kevin Tafuro

Do not share signal handlers.
Several signals are normally used to terminate a program, including SIGTERM,
SIGQUIT, and SIGINT (to name but a few). It is far too common to see code like
this:
signal(SIGINT, signal_handler);
signal(SIGTERM, signal_handler);
signal(SIGQUIT, signal_handler);
Such code is unsafe because while signal_handler( ) is handling a SIGTERM that
has been delivered to the process, a SIGINT could be delivered to the same function.
Most programmers have a tendency to write their signal handlers in a nonreentrant
fashion because the same signal will not be delivered to the process
again until the first handler returns. In addition, many programmers write their
code under the false assumption that no signals can be delivered while a signal
handler is running, which is not true.
Do as little work as is possible in a signal handler.
Only a small number of system functions are safe to call from a signal handler.
Worse, the list is different on different operating systems. Worse still, many
operating systems do not document which functions are safe, and which are not.
In general, it is a good idea to set a flag in a signal handler, and do nothing else.
Never make calls to dynamic memory allocation functions such as malloc( ) or
free( ), or any other functions that may make calls to those functions. This
includes calls to functions like syslog( )—which we’ll discuss in more detail
later in this chapter (see Recipe 13.11)—for a variety of reasons, including the
fact that it often makes calls to malloc( ) internally.
Note that on many systems, system functions like malloc( ) and free( ) are reentrant,
and can be called safely from multiple threads, but this type of reentrancy
is not the same as what is required for use by a signal handler! For thread
safety, these functions usually use a mutex to protect themselves. But what happens
if a signal is delivered to a thread while that thread is in the process of running
malloc( )? The simple answer is that the behavior is undefined. On some
systems, this might cause a deadlock because the same thread is trying to acquire
the same mutex more than once. On other systems, the acquisition of the mutex
may fail, and malloc( ) proceeds normally, resulting in a double release of the
mutex. On still other systems, there could be no multithreaded protection at all,
and the heap could become corrupted. Many other possibilities exist as well, but
these three alone should scare you enough to make the point.
If you must perform more complex operations in a signal handler than we are recommending
here, you should block signal delivery during any nonatomic operations
that may be impacted by operations performed in a signal handler. In addition, you
should block signal delivery inside all signal handlers.
Performing Proper Signal Handling | 713
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.