[Python-ideas] atexit.register_w_signals()

[Giampaolo Rodola']

On Sat, Feb 13, 2016 at 1:26 PM, Chris Angelico <rosuav at gmail.com> wrote:

> 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
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>

OK, I am convinced it makes sense to look for SIGTERM only.  Also, I now
have a better understanding of how different signal.signal() works on
Windows http://bugs.python.org/msg260201 and it probably makes no sense to
make an effort for trying to support Windows at all.

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

In this case such a kind of app wouldn't use something like
register_exit_fun(). The problems I'm trying to address are 2: run the exit
function for the most used/obvious/portable termination signal (SIGTERM),
which is what atexit lacks, and at the same time avoid to overwrite any
existing signal.signal() handler. In order to do this right now I'm
supposed to use `atexit.register` *and* a wrapper around signal.signal().

-- 
Giampaolo - http://grodola.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160213/06f53ec0/attachment.html>