12.3.96 SP_signal()

Synopsis

     #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.

Arguments

sig
The signal
fun
The function
user_data
An extra, user defined value passed to the function.

Return Value

SP_SIG_ERR if an error occurs error. On success, some value different from SP_SIG_ERR.

Description

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:

  1. If a signal handler for 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.
  2. If a signal handler has not been installed with 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.

See Also

SP_event(), Signal Handling.


Send feedback on this subject.