gh-84559: improve What's New entry for multiprocessing start method changes by picnixz · Pull Request #128173 · python/cpython (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation12 Commits9 Checks26 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Member
•
edited by github-actionsbot
Loading
Just a note, on macOS the default is spawn (as it has been for a while). However the docs also note that POSIX uses forkserver by default. Though macOS also is a POSIX platform. Should this be disambiguated somehow?
Though macOS also is a POSIX platform. Should this be disambiguated somehow
Ah yes, sorry. it should have been "On POSIX platforms, except macOS, [...]" or "On platforms other than macOS and Windows". Which one would be the clearer?
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm glad we have a full section in the multiprocessing docs to link to (hooray past us!). But to help people from a What's New standpoint given the issues people are raising about this being confusing, I think we should pick a couple different short example error messages users might see coming out of an application that needs modification to work with the new start method when using multiprocessing or concurrent.futures.
I think we should pick a couple different short example error messages users might see coming out of an application that needs modification to work with the new start method when using multiprocessing or concurrent.futures.
What about improving the section in multiprocessing about the differences between fork and spawn/forkserver by adding some "common issues" examples (and we can add a link to that section in the What's New entries) and/or possible examples of how to upgrade from 'fork' to 'spawn/forkserver'?
I think we should pick a couple different short example error messages users might see coming out of an application that needs modification to work with the new start method when using multiprocessing or concurrent.futures.
What about improving the section in
multiprocessingabout the differences between fork and spawn/forkserver by adding some "common issues" examples (and we can add a link to that section in the What's New entries) and/or possible examples of how to upgrade from 'fork' to 'spawn/forkserver'?
Even just a sentence in What's New saying something along the lines of "if you are seeing name errors of pickling errors coming out of multiprocessing or concurrent.futures when you upgrade to 3.14, read ...link-to-section..." would help people understand. Expanding further upon that kind of thing in the multiprocessing docs as common issues would be good.
Co-authored-by: Stan Ulbrych 89152624+StanFromIreland@users.noreply.github.com
Even just a sentence in What's New saying something along the lines of "if you are seeing name errors of pickling errors coming out of multiprocessing or concurrent.futures when you upgrade to 3.14, read ...link-to-section..."
I'll have a look at what to link tomorrow and if I have the motivation, I'll do something for the mp docs.
Small ping that I ended up here after a discussion about this behavior and getting this docs improvement merged would help a lot. No rush of course but just don’t want this forgotten.
Oh I forgot... I will try to make it by the end of the weekend. Let's make it as the next task. Thanks for the ping !
seehwan pushed a commit to seehwan/cpython that referenced this pull request
…method changes (python#128173)
Co-authored-by: Gregory P. Smith greg@krypto.org Co-authored-by: Stan Ulbrych 89152624+StanFromIreland@users.noreply.github.com