Skip to content

Remove our own tokio runtime and use the one provided by pyo3-async-runtimes #441

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

kylebarron
Copy link
Member

@kylebarron kylebarron commented May 9, 2025

cc @ion-elgreco ; any thoughts? You previously mentioned here that we should check for forked processes. I'm curious if you've considered using the runtime provided by pyo3-async-runtimes?

Closes #419

@ion-elgreco
Copy link

I believe the forked processes checking remains, pyo3-async also uses Tokio right?

Pyo3-async didn't make much sense for delta-rs because all methods in python are sync, and the rust code is async

@kylebarron
Copy link
Member Author

I believe the forked processes checking remains, pyo3-async also uses Tokio right?

pyo3-async-runtimes does use tokio, but I don't think it has as nice of a check as was here. I figure tokio will just silently stop working if the python user tries to multiprocess?

@ion-elgreco
Copy link

ion-elgreco commented May 9, 2025

I believe the forked processes checking remains, pyo3-async also uses Tokio right?

pyo3-async-runtimes does use tokio, but I don't think it has as nice of a check as was here. I figure tokio will just silently stop working if the python user tries to multiprocess?

It might deadlock or panic actually if you use fork

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

Successfully merging this pull request may close these issues.

Use get_runtime from pyo3-async-runtimes instead of creating our own tokio runtime
2 participants