As of version 3.1.0, SWI-Prolog is capable to handle software interrupts (signals) in Prolog as well as in foreign (C) code (see section 9.4.12).
Signals are used to handle internal errors (execution of a non-existing CPU instruction, arithmetic domain errors, illegal memory access, resource overflow, etc.), as well as for dealing asynchronous inter-process communication.
Signals are defined by the POSIX standard and part of all Unix machines. The MS-Windows Win32 provides a subset of the signal handling routines, lacking the vital functionality to raise a signal in another thread for achieving asynchronous inter-process (or inter-thread) communication (Unix kill() function).
on_signal(Signal, Current, Current)
.
The action description is an atom denoting the name of the predicate that will be called if Signal arrives. on_signal/3 is a meta-predicate, which implies that <Module>:<Name> refers the <Name>/1 in the module <Module>. The handler is called with a single argument: the name of the signal as an atom. The Prolog names for signals is explained below.
Two predicate-names have special meaning. throw
implies
Prolog will map the signal onto a Prolog exception as described in
section 4.9. default
resets the handler to the settings active before SWI-Prolog manipulated
the handler.
Signals bound to a foreign function through PL_signal()
are reported using the term $foreign_function(Address)
.
After receiving a signal mapped to throw
, the exception
raised has the structure
error(signal(<SigName>, <SigNum>), <Context>)
The signal names are defined by the POSIX standard as symbols of the form SIG<SIGNAME>. The Prolog name for a signal is the lowercase version of <SIGNAME>. The predicate current_signal/3 may be used to map between names and signals.
Initially, some signals are mapped to throw
, while all
other signals are default
. The following signals throw an
exception:
fpe
, alrm
, xcpu
, xfsz
and vtalrm
.
Before deciding to deal with signals in your application, please consider the following:
throw
are unsafe. Handlers defined to call a predicate are safe. Note that the
predicate can call throw/1,
but the delivery is delayed until Prolog is in a safe state.
The C-interface described in section
9.4.12 provides the option
PL_SIGSYNC
to select either safe synchronous or unsafe
asynchronous delivery.
throw
or a foreign handler, signals are delivered
immediately (as defined by the OS). When using a Prolog predicate,
delivery is delayed to a safe moment. Blocking system calls or foreign
loops may cause long delays. Foreign code can improve on that by calling PL_handle_signals().
Signals are blocked when the garbage collector is active.