9.4.21.1 Threading, Signals and embedded Prolog

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 applications, however, are by nature multithreaded and appear to do signal handling (software interrupts).

On Unix systems, SWI-Prolog uses three signals:

SIGUSR1

is used to sychronise atom and clause garbage collection. The handler is installed at the start of garbage collection and reverted to the old setting after completion.

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.

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.

The --nosignals option can be used to inhibit processing of SIGINT. The other signals are vital for the functioning of SWI-Prolog. If they conflict with other applications, signal handling of either component must be modified. The SWI-Prolog signals are defined in pl-thread.h of the source distribution.