This crate provides experimental support for multi-producer/multi-consumer channels. This includes rendezvous, synchronous and asynchronous channels.
Channels are never complete without a way to synchronize on multiple channels
at the same time. Therefore, this crate provides a chan_select!
macro that
can select on any combination of channel send or receive operations.
Dual-licensed under MIT or the UNLICENSE.
Documentation
Please help me improve the documentation!
http://burntsushi.net/rustdoc/chan/
Example: selecting on multiple channels
extern crate chan;
use thread;
Example: wait for OS signals
This requires the chan-signal
crate on crates.io.
extern crate chan;
extern crate chan_signal;
use Signal;
use thread;
Differences with std::sync::mpsc
Rust's standard library has a multi-producer/single-consumer channel. Here are the differences (which I believe amount to a massive increase in ergonomics):
chan
channels are multi-producer/multi-consumer, so you can clone senders and receivers with reckless abandon.chan
uses nounsafe
code.chan
's asynchronous channels have lower throughput thanstd::sync::mpsc
. (Run the benchmarks withcargo bench
.)chan
's synchronous channels have comparable throughput withstd::sync::mpsc
.chan
has a select macro that works on stable and can synchronize across channel send or receive operations. It also supports a "default" case that is executed when all channel operations are blocked. (This effectively replaces uses oftry_send
/try_recv
instd::sync::mpsc
. Indeed,chan
omits these methods entirely.)chan
's send operations will deadlock if all receivers have been dropped. This is a deliberate choice inspired by Go. I'm open to changing it.chan
's channels implementSync
. When we get a working scoped API, you won't need to clone channels to pass them into other threads (when you can prove that the channel outlives the thread of course).
Motivation
The purpose of this crate is to provide a safe concurrent abstraction for
communicating sequential processes. Performance takes a second seat to
semantics and ergonomics. If you're looking for high performance
synchronization, chan
is probably not the right fit.
Moreover, chan
synchronizes across operating system threads, so in order to
spin up multiple concurrent routines, you need to launch a thread for each one.
This may be more cost than you're willing to pay.
Bottom line: chan
doesn't have any place in a high performance web server,
but it might have a place in structuring coarse grained concurrency in
applications.
Also...
chan-signal is a Rust library
for using channels in chan
to receive OS signals. (Unix only at the moment.)
cmail is a program to periodically email the output of long running commands. I ported this from an earlier version that I wrote in Go.