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

Panic when dropping tokio SendHalf on Windows #71

Open
florian-g2 opened this issue Sep 6, 2024 · 3 comments
Open

Panic when dropping tokio SendHalf on Windows #71

florian-g2 opened this issue Sep 6, 2024 · 3 comments
Labels
bug Something isn't working

Comments

@florian-g2
Copy link

Describe the bug
The drop implementation of a SendHalf panics with "fresh Tokio limbo helper died immediately after being created" when the SendHalf is dropped in result to a tokio runtime shutdown.

This happens because the limbo helper inside interprocess tries to spawn a task on a shutdown runtime.
The task is immediately dropped along with the passed mspc receiver. The panic occurs because the corpse sender expects a open channel.

To Reproduce
Minimal code to reproduce the panic:
https://github.com/florian-g2/interprocess-drop-panic

Expected behavior
No panic.

Notes
I have a possible fix ready in a few moments.

@florian-g2 florian-g2 added the bug Something isn't working label Sep 6, 2024
florian-g2 added a commit to florian-g2/interprocess that referenced this issue Sep 7, 2024
The send_off method now properly falls back to a static tokio runtime if required.
@federico-terzi
Copy link

I'm also experiencing the same problem on Windows, and flushing the SendHalf (and awaiting) before shutting down the tokio runtime doesn't seem to solve the problem

I'm wondering if it would be worth it to introduce an option to sacrifice the delivery guarantee and skip the limbo entirely

@kotauskas
Copy link
Owner

I'm wondering if it would be worth it to introduce an option to sacrifice the delivery guarantee and skip the limbo entirely

Flushing is supposed to be that option. The fact that it doesn't prevent a panic suggests an additional performance bug.

@LonerDan
Copy link

LonerDan commented Nov 7, 2024

I have encountered this error myself recently. Perhaps the LIMBO_RT should be pre-initialized during the connection creation instead of ad-hoc during the first send_off call?
I have added a few milliseconds of tokio::time::sleep to my tokio::main after the connection is dropped which seems to at least alleviate this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants