| |
 | Preventing Glitches in Signal Processing
By Danny Kalev, C++ Pro
|
Signals are similar to hardware interrupts. They cause a process to branch from the current execution flow, perform a specific action, and resume execution from the point of interruption. In the following sections, I will dissect the ANSI <signal.h> library and demonstrate how to use its interfaces. We will then proceed to the POSIX signal API.
By default, certain signals cause a process to terminate. For example, an attempt to access memory that the process doesn't own fires a SIGSEGV ("segmentation fault") signal, which in turn aborts the process. Yet for many applications, this is undesirable. Debuggers, emulators, and transaction processing systems must handle such signals and continue to run.
By default, certain signals cause a process to terminate, no questions asked. How can this be prevented?
Install handlers for incoming signals and catch them when they occur.
|
|
Find Out More
• All DevX 10-Minute Solutions for C/C++
• Signal Processing Notes
• About the Kill() System Call
• Perl and Signaling
• DevX Tip Library: Re-entrant Functions
• From Linux Magazine: Signal Processing
• Posix Signals
 | TALK BACK |
While the POSIX signal API is more advanced than the ANSI <signal.h> library, it's confined to the Unix/Linux domain. Do you think the ANSI standardization committee should adopt it and deprecate the traditional <signal.h> library? Give us your take in our C++ discussion group.
 |
|
