[Python-ideas] atexit.register_w_signals()

[Chris Angelico]

On Sat, Feb 13, 2016 at 10:35 PM, Giampaolo Rodola' <g.rodola at gmail.com> wrote:
> Yeah, that is true. But there are certain signals which are undoubtedly
> designed to terminate a process: SIGTERM / SIGINT, which are the most used,
> and SIGQUIT / SIGABRT, which I've personally never used but their meaning is
> quite obvious. What people want most of the times is to address *those*
> signal, and if they want to do something different (e.g. associate SIGHUP)
> they can simply pass it as an argument (register_exit_func(signals=[SIGTERM,
> SIGHUP])).
>

SIGTERM is generally expected to terminate a process cleanly. SIGQUIT
is an unclean termination, and by default will dump core as well as
terminating. SIGABRT is often sent from the process itself (via the
abort() C function), and normally means a critical invariant has been
broken (eg trampling all over vital memory structures like the stack
or heap). SIGINT is a standard "break" signal, and doesn't always mean
process termination at all (start an infinite loop in interactive
Python, then hit Ctrl-C - you expect to go back to the prompt).

Of them, only SIGTERM can consistently be interpreted as a termination
signal. Some programs treat SIGINT and SIGTERM as different forms of
termination (consider PostgreSQL - SIGTERM means "stop accepting
connections, and terminate when current connections finish", and
SIGINT means "abort current connections and shut down immediately"),
but a general library function can't assume that.

Ultimately, signals belong to the application, not a library. It's
impossible for a library to be able to implement an atexit system in
any sort of general way. If I were faced with this problem, I'd
probably make a simple way to turn a bunch of signals into raised
exceptions and do all the atexit work with context managers or finally
blocks. That would be reasonably clean, without trying to promise
something that won't always make sense.

ChrisA