This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eryksun
Recipients davin, eryksun, neologix, pietvo, pitrou, sbt, tim.peters
Date 2016-07-14.15:58:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1468511892.27.0.865192119542.issue18966@psf.upfronthosting.co.za>
In-reply-to
Content
> all atexit handlers, for example, would be called multiple times.

Davin is (I think) proposing a multiprocessing atexit facility, which can be used to ensure threading._shutdown is called. But could Python's regular atexit handling be reset in the child, allowing Py_Finalize to be called? In other words, can atexit can be integrated into the PyOS_AfterFork (Modules/signalmodule.c) sequence? multiprocessing could set a sys flag that forces atexit to clear its registered handlers, and for Py_AtExit, reset the static nexitfuncs variable in Python/pylifecycle.c. Or is that just opening a can of worms that will cause Py_Finalize to crash in various scenarios?

> There's also the problem that fork() isn't MT-safe

This issue is about joining Python threads created in the child, which has a clean slate via PyOS_AfterFork, PyEval_ReInitThreads (Python/ceval.c), and threading._after_fork.
History
Date User Action Args
2016-07-14 15:58:12eryksunsetrecipients: + eryksun, tim.peters, pitrou, pietvo, neologix, sbt, davin
2016-07-14 15:58:12eryksunsetmessageid: <1468511892.27.0.865192119542.issue18966@psf.upfronthosting.co.za>
2016-07-14 15:58:12eryksunlinkissue18966 messages
2016-07-14 15:58:12eryksuncreate