This section applies to Unix-based environments that have signals or
multithreading. The Windows version is compiled for multithreading, and
Windows lacks proper signals.
We can distinguish two classes of embedded executables. There are
small C/C++ programs that act as an interfacing layer around Prolog.
Most of these programs can be replaced using the normal Prolog
executable extended with a dynamically loaded foreign extension and in
most cases this is the preferred route. In other cases, Prolog is
embedded in a complex application that---like Prolog---wants to control
the process environment. A good example is Java. Embedding Prolog is
generally the only way to get these environments together in one process
image. Java VMs, however, are by nature multithreaded and appear to do
signal handling (software interrupts).
On Unix systems, SWI-Prolog installs handlers for the following
signals:
- SIGUSR2
- has an empty signal handler. This signal is sent to a thread after
sending a thread-signal (see
thread_signal/2).
It causes blocking system calls to return with
EINTR, which
gives them the opportunity to react to thread-signals.
In some cases the embedded system and SWI-Prolog may both use
SIGUSR2 without conflict. If the embedded system redefines
SIGUSR2 with a handler that runs quickly and no harm is
done in the embedded system due to spurious wakeup when initiated from
Prolog, there is no problem. If SWI-Prolog is initialised
after the embedded system it will call the handler set by the
embedded system and the same conditions as above apply. SWI-Prolog's
handler is a simple function only chaining a possibly previously
registered handler. SWI-Prolog can handle spurious
SIGUSR2 signals.
- SIGINT
- is used by the top level to activate the tracer (typically bound to
control-C). The first control-C posts a request for starting the tracer
in a safe, synchronous fashion. If control-C is hit again before the
safe route is executed, it prompts the user whether or not a forced
interrupt is desired.
- SIGTERM, SIGABRT and SIGQUIT
- are caught to cleanup before killing the process again using the same
signal.
- SIGSEGV, SIGILL, SIGBUS, SIGFPE and SIGSYS
- are caught by to print a backtrace before killing the process again
using the same signal.
- SIGHUP
- is caught and causes the process to exit with status 2 after cleanup.
The --no-signals option can be used to inhibit all
signal processing except for SIGUSR2. The handling of SIGUSR2
is vital for dealing with blocking system call in threads. The used
signal may be changed using the --sigalert=NUM option
or disabled using --sigalert=0.
