Crossfire: High-performance lockless spsc/mpsc/mpmc channels for Rust
1–10 of 22 posts
Re: Crossfire: High-performance lockless spsc/mpsc/mpmc channels for Rust
#2Because I had to look it up:
SPSC = Single Producer Single Consumer
MPMC = Multiple Producer Multiple Consumer
(I'll let you deduce the other abbreviations)
Re: Crossfire: High-performance lockless spsc/mpsc/mpmc channels for Rust
#3When 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.
[0]: https://github.com/frostyplanet/crossfire-rs/wiki#kanal [1]: https://news.ycombinator.com/item?id=45774086
Re: Crossfire: High-performance lockless spsc/mpsc/mpmc channels for Rust
#4When 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. [0]: https://github.com/frostyplanet/crossfire-rs/wiki#kanal [1]: https://news.yco…
Futurelock is not about cancellation safety (cancellation is actually one solution to futurelock), though the related issues that are linked in that post are.
Re: Crossfire: High-performance lockless spsc/mpsc/mpmc channels for Rust
#5For Java/JVM :
Re: Crossfire: High-performance lockless spsc/mpsc/mpmc channels for Rust
#6I 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).
Re: Crossfire: High-performance lockless spsc/mpsc/mpmc channels for Rust
#7Because I had to look it up: SPSC = Single Producer Single Consumer MPMC = Multiple Producer Multiple Consumer (I'll let you deduce the other abbreviations)
S = Single
M = Multi
---
C = Consumer
P = Producer
Re: Crossfire: High-performance lockless spsc/mpsc/mpmc channels for Rust
#8When 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. [0]: https://github.com/frostyplanet/crossfire-rs/wiki#kanal [1]: https://news.yco…
Cancellation safety is another thing entirely, but one about which there's also an oxide RFD https://rfd.shared.oxide.computer/rfd/400
Re: Crossfire: High-performance lockless spsc/mpsc/mpmc channels for Rust
#9Using stuff like this, does it make sense to use Rust in a golang-style where instead of async and its function colouring, you spawn coroutines and synchronize over channels?
Re: Crossfire: High-performance lockless spsc/mpsc/mpmc channels for Rust
#10Using stuff like this, does it make sense to use Rust in a golang-style where instead of async and its function colouring, you spawn coroutines and synchronize over channels?
It doesn't matter if you use channels or mutexes to communicate between tasks, you still need your function to be async to spawn it as a coroutine. Your only choice is between coroutines (async tasks spawned on an executor) or regular OS threads. Channels work with both, the rule of thumb is to use async when your workload is IO-bound, and threads when it is compute-bound. Then, it's up to you whether you communicate by sharing memory or share memory by communicating.