Panic when dropping tokio SendHalf on Windows

[florian-g2]

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.

[federico-terzi]

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]

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]

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.

[kotauskas]

As of the linger pool rewrite, there are no longer any calls to Tokio in any destructors. 1f1b9bd adds the regression test off_runtime_drop that closely resembles the original reproduction in https://github.com/florian-g2/interprocess-drop-panic.