[issue16500] Add an 'atfork' module

Antoine Pitrou added the comment: I've posted https://github.com/python/cpython/pull/1715 which adds a single `os.register_at_fork` function to allow registering at-fork handlers. Comments welcome. -- stage: -> patch review versions: +Python 3.7 -Python 3.5 _

[issue16500] Add an 'atfork' module

Changes by Antoine Pitrou : -- pull_requests: +1805 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue16500] Add an 'atfork' module

Changes by A. Jesse Jiryu Davis : -- nosy: +emptysquare ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:/

[issue16500] Add an 'atfork' module

Марк Коренберг added the comment: Also I have to add, maybe you also add automatic file descriptor closing on fork. We already have O_CLOEXEC, we have no O_CLOFORK. So, maybe it useful to add such flag ? -- ___ Python tracker

[issue16500] Add an 'atfork' module

Changes by Марк Коренберг : -- nosy: +mmarkk ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue16500] Add an 'atfork' module

Changes by Robert Cope : -- nosy: +rpcope1 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.

[issue16500] Add an 'atfork' module

Changes by Ionel Cristian Mărieș : -- nosy: +ionelmc ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue16500] Add an 'atfork' module

Changes by Yury Selivanov : -- nosy: +yselivanov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue16500] Add an 'atfork' module

Changes by xupeng : -- nosy: +xupeng ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/ma

[issue16500] Add an 'atfork' module

Changes by Antoine Pitrou : -- versions: +Python 3.5 -Python 3.4 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue16500] Add an 'atfork' module

Richard Oudkerk added the comment: It is a recent kernel and does support pipe2(). After some debugging it appears that a pipe handle created in Popen.__init__() was being leaked to a forked process, preventing Popen.__init__() from completing before the forked process did. Previously the tes

[issue16500] Add an 'atfork' module

STINNER Victor added the comment: The PEP 446 does not offer any warranty on the atomicity on clearing the inheritable flag. -- ___ Python tracker ___ ___

[issue16500] Add an 'atfork' module

Charles-François Natali added the comment: > Given PEP 446 (fds are now CLOEXEC by default) I prepared an updated patch > where the fork lock is undocumented and subprocess no longer uses the fork > lock. (I did not want to encourage the mixing of threads with fork() without > exec() by expos

[issue16500] Add an 'atfork' module

Richard Oudkerk added the comment: Given PEP 446 (fds are now CLOEXEC by default) I prepared an updated patch where the fork lock is undocumented and subprocess no longer uses the fork lock. (I did not want to encourage the mixing of threads with fork() without exec() by exposing the fork loc

[issue16500] Add an 'atfork' module

Charles-François Natali added the comment: > Well it is customary for callback-based APIs to hold strong references to > their callbacks. If a library wants to avoid leaks, it should register a > single callback which will then walk the current "live" resources and protect > them. I guess tha

[issue16500] Add an 'atfork' module

Antoine Pitrou added the comment: > One of the main use cases for atfork hooks would be the numerous stdlib objects which have locks (or locks themselves): most of such objects have arbitrary lifetimes (e.g. logging, events, open files, etc). > The risk of leak is IMO much greater. Well it is cu

[issue16500] Add an 'atfork' module

Charles-François Natali added the comment: > Richard Oudkerk added the comment: > >> - now that FDs are non-inheritable by default, fork locks around >> subprocess and multiprocessing shouldn't be necessary anymore? What >> other use cases does the fork-lock have? > > CLOEXEC fds will still be in

[issue16500] Add an 'atfork' module

Richard Oudkerk added the comment: > - now that FDs are non-inheritable by default, fork locks around > subprocess and multiprocessing shouldn't be necessary anymore? What > other use cases does the fork-lock have? CLOEXEC fds will still be inherited by forked children. > - the current implemen

[issue16500] Add an 'atfork' module

STINNER Victor added the comment: "now that FDs are non-inheritable by default, fork locks around subprocess and multiprocessing shouldn't be necessary anymore? What other use cases does the fork-lock have?" Well, on Windows, it's still not possible to inherit only one handle. If you mark tempo

[issue16500] Add an 'atfork' module

Charles-François Natali added the comment: I have a couple random remarks: - now that FDs are non-inheritable by default, fork locks around subprocess and multiprocessing shouldn't be necessary anymore? What other use cases does the fork-lock have? - the current implementation keeps hard-referenc

[issue16500] Add an 'atfork' module

Christian Heimes added the comment: +1 for exception prevents fork -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue16500] Add an 'atfork' module

Dwayne Litzenberger added the comment: > The main question is whether a failed prepare callback should prevent the > fork from happenning Yes, I think an exception should prevent the fork from happening. It's fail-safe for the PRNG case (you can guarantee that a fork won't occur without prope

[issue16500] Add an 'atfork' module

Richard Oudkerk added the comment: > Richard, do you have time to get your patch ready for 3.4? Yes. But we don't seem to have concensus on how to handle exceptions. The main question is whether a failed prepare callback should prevent the fork from happenning, or just be printed. -

[issue16500] Add an 'atfork' module

Christian Heimes added the comment: Richard, do you have time to get your patch ready for 3.4? -- assignee: christian.heimes -> ___ Python tracker ___ __

[issue16500] Add an 'atfork' module

Changes by Aaron Iles : -- nosy: +aliles ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.or

[issue16500] Add an 'atfork' module

Changes by Dwayne Litzenberger : -- nosy: +DLitz ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue16500] Add an 'atfork' module

Changes by Antoine Pitrou : -- nosy: +neologix ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue16500] Add an 'atfork' module

Antoine Pitrou added the comment: > It sounds strange to mix "at exit" and "at fork" in the same module. > Both are very different. That's true. The sys module would probably be the right place for both functionalities. -- ___ Python tracker

[issue16500] Add an 'atfork' module

Marc-Andre Lemburg added the comment: On 13.01.2013 00:37, STINNER Victor wrote: > By the way, OpenSSL expects that its PRNG is reseed somehow (call RNG_add) > after a fork. I wrote a patch for OpenSSL, but I don't remember if I sent it > to OpenSSL. > https://bitbucket.org/haypo/hasard/src/4a1

[issue16500] Add an 'atfork' module

STINNER Victor added the comment: > Might make sense to put this in atexit.atfork() to avoid small-module > inflation? It sounds strange to mix "at exit" and "at fork" in the same module. Both are very different. 2013/1/13 Arfrever Frehtes Taifersar Arahesis : > > Changes by Arfrever Frehtes T

[issue16500] Add an 'atfork' module

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue16500] Add an 'atfork' module

Georg Brandl added the comment: Might make sense to put this in atexit.atfork() to avoid small-module inflation? -- nosy: +georg.brandl ___ Python tracker ___ ___

[issue16500] Add an 'atfork' module

STINNER Victor added the comment: "The tempfile module has a specialized RNG that re-initialized the RNG after fork() by comparing os.getpid() to an instance variable every time the RNG is accessed. The check can be replaced with an afterfork callback." By the way, OpenSSL expects that its PRN