This crate has reached its end-of-life and is now deprecated.

The intended successor of this crate is the crossbeam-channel crate. Its API is strikingly similar, but comes with a much better select! macro, better performance, a better test suite and an all-around better implementation.

If you were previously using this crate because of chan-signal, then it is simple to reproduce a similar API with crossbeam-channel and the signal-hook crate. For example, here's chan-signal's notify function:

use crossbeam_channel::Receiver;

fn notify(signals: &[c_int]) -> Result<Receiver<c_int>> {
    let (s, r) = crossbeam_channel::bounded(100);
    let signals = signal_hook::iterator::Signals::new(signals)?;
    thread::spawn(move || {
        for signal in signals.forever() {
            s.send(signal);
        }
    });
    Ok(r)
}

This crate may continue to receives bug fixes, but should otherwise be considered dead.

chan

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

#[macro_use]
extern crate chan;

use std::thread;

fn main() {
    let tick = chan::tick_ms(100);
    let boom = chan::after_ms(500);
    loop {
        chan_select! {
            default => { println!("   ."); thread::sleep_ms(50); },
            tick.recv() => println!("tick."),
            boom.recv() => { println!("BOOM!"); return; },
        }
    }
}

Example: wait for OS signals

This requires the chan-signal crate on crates.io.

#[macro_use]
extern crate chan;
extern crate chan_signal;

use chan_signal::Signal;
use std::thread;

fn main() {
    // Signal gets a value when the OS sent a INT or TERM signal.
    let signal = chan_signal::notify(&[Signal::INT, Signal::TERM]);
    // When our work is complete, send a sentinel value on `sdone`.
    let (sdone, rdone) = chan::sync(0);
    // Run work.
    thread::spawn(move || run(sdone));

    // Wait for a signal or for work to be done.
    chan_select! {
        signal.recv() -> signal => {
            println!("received signal: {:?}", signal)
        },
        rdone.recv() => {
            println!("Program completed normally.");
        }
    }
}

fn run(_sdone: chan::Sender<()>) {
    println!("Running work for 5 seconds.");
    println!("Can you send a signal quickly enough?");
    // Do some work.
    thread::sleep_ms(5000);

    // _sdone gets dropped which closes the channel and causes `rdone`
    // to unblock.
}

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 no unsafe code.
• chan's asynchronous channels have lower throughput than std::sync::mpsc. (Run the benchmarks with cargo bench.)
• chan's synchronous channels have comparable throughput with std::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 of try_send/try_recv in std::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 implement Sync. 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.