-
Notifications
You must be signed in to change notification settings - Fork 831
(Experimental) support of the nogil fork of CPython #3125
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
Please have a look at #2885 where some conservation on this has already happened. |
Weird I didn't find anything when GitHub searching for "nogil" we can close as duplicate |
Ah I was only searching issues, not PRs |
No worries. Maybe you can use the code proposed in the PR can be brought to bear onto your use case. Ideally after a rebase though. |
Luckily we sidestep the "library" issue with nogil, since we're shipping a python binary and application. We all are just using pyo3 to consume frozen dataclasses (with possible references to other frozen dataclasses) run some rust code on the data, then construct and return other frozen dataclasses. In a pool of threads. Since we aren't mutating objects, I suspect nogil will cause much less contention in the threads, so I'm excited to try it out |
👋 love PyO3!
We have a use case for trying out the nogil fork of CPython (https://github.com/colesbury/nogil-3.12/tree/nogil-3.9) but I don't think we'll get very far until we refactor and recompile our code which relies heavily on PyO3.
I can't say I understand the impact at any level, but thought I'd throw this on the radar and get the conversation going.
The text was updated successfully, but these errors were encountered: