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

fix(python): release GIL on most operations #2512

Merged
merged 4 commits into from
May 17, 2024

Conversation

adriangb
Copy link
Contributor

Fixes #2269

@github-actions github-actions bot added the binding/python Issues for the Python package label May 14, 2024
Copy link

ACTION NEEDED

delta-rs follows the Conventional Commits specification for release automation.

The PR title and description are used as the merge commit message. Please update your PR title and description to match the specification.

@adriangb adriangb changed the title Release GIL on most operations fix(python): Release GIL on most operations May 14, 2024
@adriangb
Copy link
Contributor Author

adriangb commented May 14, 2024

@ion-elgreco could you kick off CI please? It might be worth allowing repeat contributor's to run CI automatically.

Never mind, it was just stuck.

@adriangb adriangb changed the title fix(python): Release GIL on most operations fix(python): release GIL on most operations May 14, 2024
Copy link

@davidhewitt davidhewitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although I am not familiar with the delta-rs codebase, @adriangb suggested I might want to take a quick look at this given the pain with blocking on IO and holding the GIL at the same time.

For what it's worth, I agree that it's a problem and this PR is the current solution. It does sadden me a bit that it's so verbose to have to do this, though.

Upstream in PyO3 we're looking at a #[pyo3(allow_threads)] attribute on functions which will do this for you behind the scenes - PyO3/pyo3#3610

There's also the question of more radical changes like automatically releasing the GIL when none of the input arguments need the GIL but there's a performance cost to releasing the GIL so I think it needs to be user choice.

Finally, I see that you use futures here so maybe there's a good argument that more investment in PyO3's async story would solve this in a different way by allowing you to make these functions async and allow a Python reader to await them. There are definitely complexities in mixing Rust and Python async runtimes so that's not an easy solution either.

@ion-elgreco
Copy link
Collaborator

@davidhewitt @adriangb was quite busy this week, so hadn't gotten time to look at until now : )

Yeah it's fine to release the GIL where possible, there was never really a need for it before, so I guess that's why it wasn't brought up outside of that other PR which wasn't finished.

@davidhewitt I think a derive allow_threads is definitely useful if the whole function can release the GIL.

I am not sure, what pyo3 async would provide us though

@ion-elgreco
Copy link
Collaborator

Thanks! @adriangb

@ion-elgreco ion-elgreco merged commit 6de2a5b into delta-io:main May 17, 2024
22 of 23 checks passed
@adriangb adriangb deleted the release-gil branch May 17, 2024 21:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
binding/python Issues for the Python package
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants