Skip to content
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

Open
goodboy opened this issue Aug 11, 2020 · 2 comments
Open

Roll our own os.fork() server on *nix? #146

goodboy opened this issue Aug 11, 2020 · 2 comments
Labels
enhancement New feature or request experiment Exploratory design and testing help wanted Extra attention is needed

Comments

@goodboy
Copy link
Owner

goodboy commented Aug 11, 2020

mulitprocessing's forkserver has proven severely unreliable for nested process launching (#84, #134) however it is much much faster then our current trio (aka async wrapped subprocess) 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:

  • benchmarking a spawner written with supervise_api
    • the test set is probably handy to read for digging into this
    • understanding the recommended use of sfork()
  • looking at how we could build our own version of mp's fork request loop using sfork which does minimal tractor templated process environment copying via a specific supervisor process

I'd love to get @catern's feedback on a sensible direction with the fast forking sub-system design as well 🏄

@goodboy goodboy added enhancement New feature or request help wanted Extra attention is needed experiment Exploratory design and testing labels Aug 11, 2020
@goodboy
Copy link
Owner Author

goodboy commented Aug 26, 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" 😆

@goodboy goodboy mentioned this issue Oct 16, 2020
2 tasks
@goodboy goodboy mentioned this issue Dec 23, 2020
@goodboy goodboy changed the title Process launching speedups: Roll our own "fork server" on *nix? Roll our own os.fork() server on *nix? Apr 5, 2021
@goodboy
Copy link
Owner Author

goodboy commented Apr 5, 2021

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
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
Projects
None yet
Development

No branches or pull requests

1 participant