Async_unix.SignalSourceSignal handling.
To discourage use of the Signal.Expert module, we hide it here. People can use Core.Signal.Expert if they need.
include module type of Core.Signal
with type t = Core.Signal.t
with module Expert := Core.Signal.Expertinclude Bin_prot.Binable.S with type t := tinclude Bin_prot.Binable.S_only_functions with type t := tThis function only needs implementation if t exposed to be a polymorphic variant. Despite what the type reads, this does *not* produce a function after reading; instead it takes the constructor tag (int) before reading and reads the rest of the variant t afterwards.
include Core.Comparable.S with type t := tinclude Base.Comparable.S with type t := tinclude Base.Comparisons.S with type t := tascending is identical to compare. descending x y = ascending y x. These are intended to be mnemonic when used like List.sort ~compare:ascending and List.sort ~cmp:descending, since they cause the list to be sorted in ascending or descending order, respectively.
clamp_exn t ~min ~max returns t', the closest value to t such that between t' ~low:min ~high:max is true.
Raises if not (min <= max).
include Base.Stringable.S with type t := tof_caml_int constructs a Signal.t given an OCaml internal signal number. This is only for the use of the Core_unix module.
to_string t returns a human-readable name: "sigabrt", "sigalrm", ...
type sys_behavior = [ | `ContinueContinue the process if it is currently stopped
*)| `Dump_coreTerminate the process and dump core
*)| `IgnoreIgnore the signal
*)| `StopStop (suspend) the process
*)| `TerminateTerminate the process
*) ]The behaviour of the system if a signal is received by a process. See include/linux/kernel.h in the Linux kernel source tree (not the file /usr/include/linux/kernel.h).
Queries the default system behavior for a signal.
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
We override values from Core.Signal that we don't want people to use with Async.
handle ?stop signals ~f arranges so that whenever a signal in signals is delivered, f is called on that signal. If f raises, then an exception will be raised to the monitor in effect when handle was called.
Multiple calls to handle with the same signal will cause all the handlers to run when that signal is delivered, not just the last handler from the last call to handle.
The first time handle is called for a signal, it will install a C signal handler for it, replacing the existing C signal handler for that signal.
If stop is passed, the Async signal handler will be uninstalled when stop resolves. (the OCaml and C signal handlers are never uninstalled, so if this is the last Async signal handler then the signal will start being ignored)
manage_by_async signal arranges so that signal starts being managed by Async, i.e. we install an OCaml signal handler for it. The behavior of that handler approximates the default signal behavior with the difference that for signals whose default behavior is to terminate the program, we run on-shutdown handlers first.
For terminating signals the exit status of the program will be indistinguishable from the signal not being handled. (see Shutdown.shutdown_with_signal_exn)
If handle is called (before or after), that takes precedence: the shutdown on signal behavior is suppressed (even if the corresponding stop ivar is determined).
terminating is a list of signals that can be supplied to handle and whose default behavior is to terminate the program: alrm hup int term usr1 usr2.
Various signals whose default_sys_behavior is `Terminate are not included:
| kill | it's not allowed to be handled | | pipe | Async already ignores this signal, since it handles EPIPE | | prof | so that we can profile things with -p | | vtalrm | it already has a handler |