[][src]Function signal_hook::low_level::emulate_default_handler

pub fn emulate_default_handler(signal: c_int) -> Result<(), Error>

Emulates the behaviour of a default handler for the provided signal.

This function does its best to provide the same action as the default handler would do, without disrupting the rest of the handling of such signal in the application. It is also async-signal-safe.

This function necessarily looks up the appropriate action in a table. That means it is possible your system has a signal that is not known to this function. In such case an error is returned (equivalent of EINVAL).

See also the register_conditional_default.


There's a short race condition in case of signals that terminate (either with or without a core dump). The emulation first resets the signal handler back to default (as the application is going to end, it's not a problem) and invokes it. But if some other thread installs a signal handler in the meantime (without assistance from signal-hook), it can happen this will be invoked by the re-raised signal.

This function will still terminate the application (there's a fallback on abort), the risk is invoking the newly installed signal handler. Note that manipulating the low-level signals is always racy in a multi-threaded program, therefore the described situation is already discouraged.

If you are uneasy about such race condition, the recommendation is to run relevant termination routine manually (exit or abort); they always do what they say, but slightly differ in externally observable behaviour from termination by a signal (the exit code will specify that the application exited, not that it terminated with a signal in the first case, and abort terminates on SIGABRT, so the detected termination signal may be different).