[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ] Handling signals

You can register signal handling procedures in Scheme. (In multithread environment, signal handlers are shared by all threads; see Signals and threads for details).

When a signal is delivered to the Scheme process, it is queued in VM, and processed in a 'safe point' where the state of VM is consistent. (Note that this makes handling of some signals such as SIGILL useless, for the process can't continue sensible execution after queuing the signal).

When you're using the gosh interpreter, the default behavior for each signal is as in the following table.

Cannot be handled in Scheme. Gosh follows the system's default behavior.
No signal handles are installed for these signals by gosh, so the process follows the system's default behavior. Scheme programs can install its own signal handler if necessary.
Gosh installs a signal handler for these signals that exits from the application with code 0.
On Linux platforms with thread support, these signals are used by the system and not available for Scheme. On other systems, these signals behaves the same as described below.
other signals
Gosh installs the default signal handler, which signals an "unhandled signal" error. Scheme programs can override it by its own signal handler.

If you're using Gauche embedded in some other application, it may redefine the default behavior.

Use the following procedures to get/set signal handlers from Scheme.

Function: set-signal-handler! signals handler
Signals may be a single signal number or a <sys-sigset> object, and handler should be either #t, #f or a procedure that takes one argument. If handler is a procedure, it will be called when the process receives one of specified signal(s), with the received signal number as an argument. It is safe to do anything in handler, including throwing an error or invoking continuation captured elsewhere. (However, continuations captured inside handler will be invalid once you return from handler).

If handler is #t, the operating system's default behavior is set to the specified signal(s). If handler is #f, the specified signals(s) will be ignored.

Note that signal handler setting is shared among threads in multithread enviornment. The handler is called from the thread which is received the signal. See Signals and threads for details.

Function: get-signal-handler signum
Returns the handler setting of a signal signum.

Function: get-signal-handlers
Returns an associative list of all signal handler settings. Car of each element of returned list is a <sys-sigset> object, and cdr of it is the handler (a procedure or a boolean value) of the signals in the set.

Macro: with-signal-handlers (handler-clause ...) thunk
A convenience macro to install signal handlers temporarily during execution of thunk. (Note: though this is convenient, this has certain dangerous properties described below. Use with caution.)

Each Handler-clause may be one of the following forms.

(signals expr ...)
Signals must be an expression that will yield either a signal, a list of signals, or a <sys-sigset> object. Installs a signal handler for signals that evaluates expr ... when one of the signals in signals is delivered.

(signals => proc)
Proc must be a procedure that takes one argument. This form installs proc as the signal handler for signals.

When the control exits from thunk, the signal handler setting before with-signal-handlers are recovered.

CAVEAT: If you're setting more than one signal handlers, they are installed in serial. If a signal is delivered before all the handlers are installed, the signal handler state may be left inconsistent. Also note that the handler setting is a global state; you can't set "thread local" handler by with-signal-handlers, although the form may mislead such misunderstanding.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

This document was generated by Ken Dickey on November, 28 2002 using texi2html