Message175967
Thanks Richard!
My first reaction was YAGNI but after I read the two tickets I now understand the need for three different hooks. I suggest that we implement our own hooks like the http://linux.die.net/man/3/pthread_atfork function, especially the order of function calls:
The parent and child fork handlers shall be called in the order in which they were established by calls to pthread_atfork(). The prepare fork handlers shall be called in the opposite order.
I like to focus on three hooks + the Python API and leave the usage of the hooks to other developers.
Proposal:
* Introduce a new module called atfork (Modules/atforkmodule.c) that is build into the core.
* Move PyOS_AfterFork to Modules/atforkmodule.c.
* Add PyOS_BeforeFork() (or PyOS_PrepareFork() ?) and PyOS_AfterForkParent()
* call the two new methods around the calls to fork() in the stdlib.
I'm not yet sure how to implement the Python API. I could either implement six methods:
atfork.register_before_fork(callable, *args, **kwargs)
atfork.register_after_fork_child(callable, *args, **kwargs)
atfork.register_after_fork_parent(callable, *args, **kwargs)
atfork.unregister_before_fork(callable)
atfork.unregister_after_fork_child(callable)
atfork.unregister_after_fork_parent(callable)
or two:
atfork.register(prepare=None, parent=None, child=None, *args, **kwargs)
atfork.unregister(prepare=None, parent=None, child=None) |
|
Date |
User |
Action |
Args |
2012-11-19 20:55:20 | christian.heimes | set | recipients:
+ christian.heimes, twouters, gregory.p.smith, sbt |
2012-11-19 20:55:20 | christian.heimes | set | messageid: <1353358520.66.0.154173493999.issue16500@psf.upfronthosting.co.za> |
2012-11-19 20:55:20 | christian.heimes | link | issue16500 messages |
2012-11-19 20:55:20 | christian.heimes | create | |
|