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.

Title: multiprocessing.util.register_after_fork inconsistency
Type: behavior Stage: resolved
Components: Windows Versions: Python 3.3, Python 3.4, Python 2.7
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: sbt, schlamar
Priority: normal Keywords:

Created on 2014-04-28 08:16 by schlamar, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (3)
msg217347 - (view) Author: Marc Schlaich (schlamar) * Date: 2014-04-28 08:16
multiprocessing.util.register_after_fork does not behave consistently on Windows because the `_afterfork_registry` is not transferred to the subprocess. The following example fails on Windows while it works perfectly on Linux:

import multiprocessing.util

def hook(*args):
    print (args)

def func():
    print ('func')

if __name__ == '__main__':
    multiprocessing.util.register_after_fork(hook, hook)
    p = multiprocessing.Process(target=func)
msg220056 - (view) Author: Richard Oudkerk (sbt) * (Python committer) Date: 2014-06-08 20:28
register_after_fork() is intentionally undocumented and for internal use.

It is only run when starting a new process using the "fork" start method whether on Windows or not -- the "fork" in its name is a hint.
msg220105 - (view) Author: Marc Schlaich (schlamar) * Date: 2014-06-09 17:47
Your statement is not correct, it does work on Windows (where fork is not available) if you register the hook on module level instead of in `__main__`.
Date User Action Args
2022-04-11 14:58:02adminsetgithub: 65571
2014-06-09 17:47:48schlamarsetmessages: + msg220105
2014-06-08 20:28:57sbtsetstatus: open -> closed
resolution: not a bug
messages: + msg220056

stage: resolved
2014-04-28 19:33:02ned.deilysetnosy: + sbt
2014-04-28 08:16:04schlamarcreate