-
Notifications
You must be signed in to change notification settings - Fork 32
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
python: Revive ws-demo #190
Conversation
dc4a846
to
66c93f2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 I believe the drop/abort handling resolves FG-9902 as well.
use an existing runtime when one exists
Worth a patch release of the crate?
tested and works for me getting a protobuf deserialization error in FG, but that seems unrelated to the current PR |
Figured it out. Turns out the GIL is held when you enter a By dropping the GIL at the appropriate times, we no longer need the |
It certainly brings us in line with the rust implementation, so we'll mark it fixed for now. Thanks.
I don't think so. It's OK to have multiple tokio runtimes. In fact, the isolation might not be such a bad thing. But it does have a cost, and I think our default should be to reuse an existing runtime when we have one. |
Revive the python ws-demo, by creating a tokio runtime on demand.
Changes here:
get_runtime_handle()
out ofwebsocket.rs
toruntime.rs
for possible future reuse.get_runtime_handle()
to reuse the current runtime, if one exists, instead of always creating a new one.shutdown_runtime
function, and invoke it from a pythonatexit
hook.Those last two are critical for avoiding SIGABRTs and deadlocks during python program exit. Since we use the
pyo3-log
forwarder, our tokio threads have a tendency to grab the GIL for logging, which means that we need to drop the GIL before blocking on anything going on in tokio.Fixes: FG-10384
Fixes: FG-9902