<<<<<<<<<<<<<<<<<

signal_handler(unix) LYMB signal_handler(unix)

NAME

signal_handler - associates LYMB actions with signals

DESCRIPTION

The signal_handler allows the user to control the behavior of the program in response to certain signals. The user can specify that a signal is to be ignored, returned to its default state, or associated with an instance of a LYMB action. In addition, the user can explicitly send signals to the LYMB process.

This class should not be instantiated. All messages are sent directly to the class. In what follows, "signum" is either a numeric signal number (e.g. 11) or its mnemonic equivalent (e.g. "SIGSEGV").

SUPERCLASS

object

INSTANCE VARIABLES

(none)

MESSAGES

ignore: signum Specify that signal "signum" is to be ignored.

default: signum Specify that the default action for "signum" is to be reinstalled.

install: (signum,action) Specify that "action" is to be sent a "do!" message whenever "signum" is caught.

raise: signum Send "signum" to self.

set_immediate: signum Specify that the signal handling action is to be invoked immediately upon receipt of a signal, rather than deferred until the next message send. This should be used for any signal caused by an instruction stream exception, such as SIGBUS or SIGSEGV. Otherwise, returning from the internal signal handler without invoking the associated action object will result in an infinite loop of signal generation, without the action object ever getting a chance to be invoked.

set_deferred: signum Specify that the signal handling action is deferred until the next message send. This is the default behavior and is used to protect against reentry into certain routines like the message passing

mechanism, the parser, the X toolkit intrinsics, etc.

EXAMPLE

/* * Script to trap segmentation violations and exit w/out dumping core */

signal_handler install:("SIGSEGV",segv_handler) set_deferred:"SIGSEGV";

actions new:segv_handler tick_actions= `signal_handler raise:SIGINTR;';

NOTES

The semantics of many of the signals are very machine dependent. Also, even for signal names whose semantics are the same from one machine to another (e.g. SIGCONT), the numeric signal numbers may be different (19 on sun4 and mips, 28 on 4d, 25 on stellar).

On System V based machines, a signal is restored to its default action after invocation of the signal handler. The signal_handler class, however, ensures that handlers get re-installed whenever they are invoked.

There are other machine-dependent aspects of signals to beware of. Some signals cannot be caught and/or ignored. Some machines block certain signals under certain circumstances. See signal(2) (System V) or signal(3) (BSD) in the Unix Reference Manual for complete system-specific details.