copy-channels

Crates.iocopy-channels
lib.rscopy-channels
version1.0.0
created_at2025-10-11 19:51:23.33548+00
updated_at2025-10-11 19:51:23.33548+00
descriptionA collection of cross-thread channels for copyable types
homepagehttps://github.com/tijsvd/copy-channels
repositoryhttps://github.com/tijsvd/copy-channels
max_upload_size
id1878497
size63,030
(tijsvd)

documentation

https://docs.rs/copy-channels

README

A collection of cross-thread channels for copyable types.

This crate provides channels for publishing data cross-thread to multiple receivers. There is no signalling, neither any form of async nor OS-based (futex etc.). Typical usage would be in an environment with a few hot-polling threads, where low latency is absolutely crucial, or with external signalling and avoiding the type of contention inherent in mutexes / rwlocks.

Watch channels publish a single value, where the receiver only cares about the latest value (seqlock).

Broadcast channels publish a stream of values, and the receiver sees all values in order.

All channels are safe to use with multiple senders, but do note that this may create spinlock-type contention when used at high throughput.

Both channels come in multiple variants. Fast channels work on any Copy type, however they contain undefined behaviour. There is a data race. And although the data race is "protected", in that we check afterwards whether or not there was contention, strict tools like miri still object, and we can't guarantee that things will always work with newer compiler technology.

Atomic channels are free from data races. These, however, come with restrictions on the type of values transferred, and may be slightly slower. Pick your poison.

Finally, native channels work only on types that are already atomic -- usefulness here is uncertain compared to a simple Arc<AtomicFoo>, although channels do provide things like versioning and checking for close.

Commit count: 0

cargo fmt