SP_signal() #include <sicstus/sicstus.h>
typedef void
SP_SigFun (int sig, void *user_data);
SP_SigFun
SP_signal(int sig,
SP_SigFun fun, void *user_data);
Installs a function fun as a handler for the signal
sig.
It will be called with sig and user_data as arguments.
SP_SIG_ERR if an error occurs error. On success,
some value different from SP_SIG_ERR.
When the OS delivers a signal sig for which
SP_signal(sig,func,...) has been called, SICStus will not call
func immediately. Instead the call to func will be delayed
until it is safe for Prolog to do so, in much the same way that functions
installed by SP_event() are handled.
Since the signal handling function func will not be called
immediately upon delivery of the signal to the process it only makes
sense to use SP_signal() to handle certain asynchronous signals
such as SIGINT, SIGUSR1, SIGUSR2. Other
asynchronous signals handled specially by the OS, such as SIGCHLD
are not suitable for handling via SP_signal(). Note that the
development system installs a handler for ‘SIGINT’, and, under
Windows, ‘SIGBREAK’, to catch keyboard interrupts. Under UNIX,
library(timeout) currently uses SIGVTALRM.
When func is called it may only call other (non SICStus) C code
and SP_event(). Note that func will be called in the main
thread.
If fun is one of the special constants SP_SIG_IGN or
SP_SIG_DFL, then one of two things happens:
sig has already been installed with SP_signal(), then the
SICStus OS-level signal handler is removed and replaced with,
respectively, SIG_IGN or SIG_DFL.
SP_signal(), then SP_signal() does
nothing and returns SP_SIG_ERR.
A signal handler installed by a foreign resource should be
uninstalled in the deinit function for the foreign
resource. This is to prevent the handler in the foreign resource
from being called after the code of the foreign resource has been
unloaded (e.g. by unload_foreign_resource/1).
Note that SP_signal() is not suitable for installing
signal handlers for synchronous signals like SIGSEGV.
SP_event(), Signal Handling.