-
Notifications
You must be signed in to change notification settings - Fork 12
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
Roll our own os.fork()
server on *nix?
#146
Labels
enhancement
New feature or request
experiment
Exploratory design and testing
help wanted
Extra attention is needed
Comments
goodboy
added
enhancement
New feature or request
help wanted
Extra attention is needed
experiment
Exploratory design and testing
labels
Aug 11, 2020
Discussion surrounding this is now happening in python-trio/trio#1614 in terms of avoiding using a server all together which would actually be the most ideal. Heh, and full conclusion is "write your own sync fork server" 😆 |
Merged
goodboy
changed the title
Process launching speedups: Roll our own "fork server" on *nix?
Roll our own Apr 5, 2021
os.fork()
server on *nix?
Motivating blog post: https://pythonspeed.com/articles/python-multiprocessing/ |
goodboy
added a commit
that referenced
this issue
Apr 29, 2021
It's clear now that special attention is needed to handle the case where a spawned `multiprocessing` proc is started but then the parent is cancelled before the child can connect back; in this case we need to be sure to kill the near-zombie child asap. This may end up being the solution to other resiliency issues seen around mp with nested process trees too. More testing is needed to be sure. Relates to #84 #89 #134 #146
Merged
goodboy
added a commit
that referenced
this issue
May 6, 2021
It's clear now that special attention is needed to handle the case where a spawned `multiprocessing` proc is started but then the parent is cancelled before the child can connect back; in this case we need to be sure to kill the near-zombie child asap. This may end up being the solution to other resiliency issues seen around mp with nested process trees too. More testing is needed to be sure. Relates to #84 #89 #134 #146
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
enhancement
New feature or request
experiment
Exploratory design and testing
help wanted
Extra attention is needed
mulitprocessing
's forkserver has proven severely unreliable for nested process launching (#84, #134) however it is much much faster then our currenttrio
(aka async wrappedsubprocess
) spawning backend and, as such, we're keeping around for benchmarking purposes for when we eventually tackle the building our own internal subsystem for fast process launching on linux.The issues with current unix forking apis is covered in quite good depth in @catern's blog post and I think it's a multiple required read before diving into this.
I've had some (very) brief discussion and there's some ideas I'd like to investigate:
supervise_api
sfork()
mp
's fork request loop usingsfork
which does minimaltractor
templated process environment copying via a specific supervisor processI'd love to get @catern's feedback on a sensible direction with the fast forking sub-system design as well 🏄
The text was updated successfully, but these errors were encountered: