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 Amaury.Forgeot.d'Arc
Recipients Amaury.Forgeot.d'Arc, christian.heimes, gregory.p.smith, sbt, twouters
Date 2012-11-20.09:11:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAGmFidY-rfqqU1HLKye8PA25YGftUZnHH=r_-OK=UM8TEytD1w@mail.gmail.com>
In-reply-to <1353372731.98.0.352773408024.issue16500@psf.upfronthosting.co.za>
Content
2012/11/20 Christian Heimes <report@bugs.python.org>

> IFF we are going to walk the hard and rocky road of exception handling,
> then we are going to need at least four hooks and a register function that
> takres four callables as arguments: register(prepare, error, parent,
> child). Each prepare() call pushes an error handling onto a stack. In case
> of an exception in a prepare handler, the error stack is popped until all
> error handlers are called. This approach allows a prepare handler to
> actually prevent a fork() call from succeeding.
>

FWIW, PyPy already has a notion of fork hooks:
https://bitbucket.org/pypy/pypy/src/b4e4017909bac6c102fbc883ac8d2e42fa41553b/pypy/module/posix/interp_posix.py?at=default#cl-682

Various subsystems (threads cleanup, import lock, threading.local...)
register their hook functions.

You may want to experiment from there :-)
A new "atfork" module would be easy to implement.
History
Date User Action Args
2012-11-20 09:11:52Amaury.Forgeot.d'Arcsetrecipients: + Amaury.Forgeot.d'Arc, twouters, gregory.p.smith, christian.heimes, sbt
2012-11-20 09:11:52Amaury.Forgeot.d'Arclinkissue16500 messages
2012-11-20 09:11:51Amaury.Forgeot.d'Arccreate