std::thread::sleep used in send_derived() of channels may cause deadlock

[solopine]

I am using tokio and this lib together, and I got deadlock in the following situation:
I use MultiAtomicArc and set BUFFER_SIZE = 8. When I send the 9th event, it will block the consumer code.
I checked the send method of MultiAtomicArc chanel in src/multi/channels/arc/atomic.rs, and found it uses std::thread::sleep instead of tokio::time::sleep (line 175), which will block the whole thread, while the consumer task spawned by tokio may be running in the same thread.

In other multi channels, there is also std::thread::sleep used.

Also, in the with_delays() of keen-retry, it also use std::thread::sleep, which block the whole thread when sending event with retry.

I am curious why not using tokio::time::sleep?

[zertyz]

Hi, Solopine.

Thanks for the report.

Indeed the Arc versions of the Multi channel were being considered for deprecation after introducing the retrying abilities -- issue r18 in https://github.com/zertyz/reactive-mutiny/blob/main/PLANNING.md.

But, recently, advancements in the keen-retry crate do allow them to continue. With an API rework, both sync and async code will be supported without issues, by using the "Retrying with Continuation Closure Pattern", as described in the keen-retry book.

I plan to address this issue soon.

Regarding keen-retry, it supports both sync & async code. You should find a corresponding with_delays() function that uses async sleeping.

[zertyz]

To complete the answer, in the mean time, please consider using the OgreArc version of the channels instead of the Arc ones.