-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
Multiprocessing code succeeds in 3.13 but fails in 3.14 #128145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I believe this is because of a change in the default start method on Linux. See #125714 (comment) for a fuller explanation. |
I don't understand how that relates to this code. How should this code be updated to work in 3.14? |
Global objects are not picked the same way they are picked now.
I believe using |
Thanks, It would be good to make it explicit in the "What's new" page that this can be a breaking change on Linux and that #84559 (comment) predicts "people requiring "fork" will have an unhappy surprise to debug in 3.14" -- that time is now upon us. |
I can think of something for improving the changelog. You're right in saying that this is a breaking change. I also think we should highligh it in the final release notes (cc @hugovk as the RM) |
Simpler test case for this from multiprocessing import Process, set_start_method
g = None
def process():
global g
print ('forked', g)
if __name__ == '__main__':
g = 1
print ('main', g)
#set_start_method('fork')
Process(target=process).start() 3.9: forked 1 |
Bug report
Bug description:
The following code runs successfully in 3.13.1 (and earlier versions) but fails in 3.14.0a3+ (5a584c8):
Run successfully, it produces this output:
In 3.14, it fails with
NameError
:This example looks stupid, but it is based on real-world test code.
CPython versions tested on:
3.11, 3.13, 3.14, CPython main branch
Operating systems tested on:
Linux
The text was updated successfully, but these errors were encountered: