classification
Title: execv (et al.) should invoke atexit handlers before executing new code
Type: enhancement Stage:
Components: Versions: Python 3.4
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: georg.brandl, nedbat, neologix, pitrou
Priority: normal Keywords:

Created on 2012-12-30 22:38 by nedbat, last changed 2013-01-21 12:55 by pitrou.

Messages (5)
msg178623 - (view) Author: Ned Batchelder (nedbat) * Date: 2012-12-30 22:38
If I register an atexit handler, and then call os.execv, the handler is not invoked before my process changes over to the new program.  Shouldn't it be?  My program is ending, so my atexit handlers should be invoked.

This is based on this coverage.py bug:  https://bitbucket.org/ned/coveragepy/issue/43/coverage-measurement-fails-on-code  If the atexit handlers were invoked as part of os.execv, it would work properly.
msg178668 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-12-31 11:44
That's a good question. Conceptually it makes sense, but I wonder if programs currently rely on os.execv not cleaning up anything: not only it doesn't call atexit handlers, but it also doesn't try to shutdown the interpreter. Which can be handy if you are using exec() in a fork() + exec() context (I think it is generally recommended to use os._exit(), not sys.exit() in a forked child).
msg178669 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2012-12-31 11:46
FTR, with C's atexit(3), the handlers are not called either on exec().
msg178670 - (view) Author: Charles-Fran├žois Natali (neologix) * (Python committer) Date: 2012-12-31 12:01
The first reason for not calling atexit handlers upon exec() is that
it wouldn't be async-safe anymore, and could result in deadlocks.
Also, since atexit handlers are inherited upon fork(), running atexit
handlers upon exec() could result in such handlers being called
several times - something which should definitely be avoided.

Note that the atexit documentation states that handlers will only be
called in case of "normal interpreter termination".

So I'm -1 on the change, the chance of breaking existing applications
is way too high.
msg180337 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-01-21 12:55
I agree with Charles-Fran├žois, this is a too risky change.
However, we could definitely have a separate "atexec" handler, like the "atfork" handlers which are proposed in issue16500.
History
Date User Action Args
2013-01-21 12:55:02pitrousetmessages: + msg180337
2012-12-31 12:01:03neologixsetmessages: + msg178670
2012-12-31 11:46:15georg.brandlsetnosy: + georg.brandl
messages: + msg178669
2012-12-31 11:44:15pitrousetversions: + Python 3.4, - Python 2.7, Python 3.3
nosy: + pitrou, neologix

messages: + msg178668

type: enhancement
2012-12-30 22:38:28nedbatcreate