of_system_int
and to_system_int
return and take respectively a signal number
corresponding to those in the system's /usr/include/bits/signum.h (or equivalent). It
is not guaranteed that these numbers are portable across any given pair of systems --
although some are defined as standard by POSIX.
of_caml_int
constructs a Signal.t given an O'Caml internal signal number. This is
only for the use of the Core_unix module.
The default behaviour of the system if these signals trickle to the top level of a program. See include/linux/kernel.h in the Linux kernel source tree (not the file /usr/include/linux/kernel.h).
default_sys_behavior t
Query the default system behavior for a signal.
can_send_to pid
returns true if pid
is running and the current process has
permission to send it signals.
sigprocmask cmd sigs
changes the set of blocked signals.
If cmd
is `Set
, blocked signals are set to those in the list sigs
.
If cmd
is `Block
, the signals in sigs
are added to the set of blocked
signals.
If cmd
is `Unblock
, the signals in sigs
are removed from the set of
blocked signals.
sigprocmask
returns the set of previously blocked signals.
sigpending ()
returns the set of blocked signals that are currently
pending.
sigsuspend sigs
atomically sets the blocked signals to sigs
and waits for
a non-ignored, non-blocked signal to be delivered. On return, the blocked
signals are reset to their initial value.
Specific signals, along with their default behavior and meaning.
Ignore
No-op; can be used to test whether the target
process exists and the current process has
permission to signal it
The Expert
module contains functions that novice users should avoid, due to their
complexity.
An OCaml signal handler can run at any time, which introduces all the semantic
complexities of multithreading. It is much easier to use Async's signal handling, see
[root:Async_unix].Signal, which does not involve multithreading, and runs user code as
ordinary Async jobs. Also, beware that there can only be a single OCaml signal
handler for any signal, so handling a signal with a Core
signal handler will
interfere if Async is attempting to handle the same signal.
All signal handler functions are called with Exn.handle_uncaught_and_exit
, to
prevent the signal handler from raising, because raising from a signal handler could
raise to any allocation or GC point in any thread, which would be impossible to
reason about.
If you do use Core
signal handlers, you should strive to make the signal handler
perform a simple idempotent action, like setting a ref.