When reading this project's wiki [0], it mentions that Kanal (another channel implementation) uses an optimization that "makes [the] async API not cancellation-safe". I wonder if this is the same / related issue to the recent HN thread on "future lock" [1]. I hadn't heard of this cancellation safety issue prior to that other HN thread.
Futurelock is not about cancellation safety (cancellation is actually one solution to futurelock), though the related issues that are linked in that post are.
I feel like testing if it'd be faster than tokio::sync::mpsc in my project, but in the context of a websocket client, the performance of just using tokio is already pretty good. Existing CPU usage is already negligible (under a minute of CPU time in >110 hours real time).
AceJohnny2•5h ago
SPSC = Single Producer Single Consumer
MPMC = Multiple Producer Multiple Consumer
(I'll let you deduce the other abbreviations)
endorphine•18m ago
M = Multi
---
C = Consumer
P = Producer