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

Multiple python Interpreters #9

Open
henrypinkard opened this issue Jun 28, 2024 · 1 comment
Open

Multiple python Interpreters #9

henrypinkard opened this issue Jun 28, 2024 · 1 comment

Comments

@henrypinkard
Copy link
Member

from previous PR:

@henrypinkard If I understand correctly, one hub device corresponds to one python interpreter. Is it possible to multiple hubs/interpreters? For example, if there were an inefficiently written python device that is constantly holding the GIL, could making multiple python devices be a way around this?

@ IvoVellekoop Technically this is possible if the interpreters use the same runtime and virtual environment. However, is multiple hubs need different virtual environments (possibly with different Python versions) a problem occurs since only one Python runtime can be loaded once at the moment. Changing this would be very complex and error prone.

This sounds like it may not be worth it for now. I'm also hopeful that the GIL will be removed once and for all

@marktsuchida
Copy link
Member

I agree that the PEP 684 multiple interpreters is not worth the limitations and complexity it would introduce. If we want that, we'd be much better off spinning up multiple Python processes, which I think is not out of the question if done right (i.e., without yet another from-scratch communication protocol).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants