lossy-chan

This package provides fast, bounded, and lossy broadcast channels backed by a ring buffer.

As long as receivers keep up with senders, a lossy-chan acts as a regular channel. For example:

(i, o) <- LC.new 64       -- buffer size
for_ [0..1000] $ \m -> do
    LC.send i m
    m' <- LC.receive o
    assertM (m' == m)

If a receiver lags behind, it loses access to the oldest messages first. For example:

(i, o) <- LC.new 64
for_ [0..64] (LC.send i)  -- sends 65 messages
m' <- LC.receive o
assertM (m' == 1)         -- 0 was dropped

A lossy-chan channel is split into an input and an output channel, both of which are thread-safe. If you use a single output channel in two threads, the messages are split between the two. If you want two output channls that both receive every message, you can duplicate the output channel. The new output channel receives messages starting where the duplicated channel left off. For example:

(i, o1) <- LC.new 64
for_ [1,2] (LC.send i)

m1 <- LC.receive o1
assertM (m1 == 1)         -- receive the 1 on o1

o2 <- LC.dup o1           -- duplicate o1
m2 <- LC.receive o2       -- receive the 2 on o2
assertM (m2 == 2)

m2' <- LC.receive o1      -- receive the 2 on o1
assertM (m2' == 2)

The lossy-chan buffer uses access counts to ensure that messages can be garbage collected as soon as they've been received by every output channel. This relies on finalizers and is not guaranteed to be prompt. For example:

(i, o) <- LC.new 64
LC.send i bigThing
void (LC.receive o)       -- bigThing can now be garbage collected

If the input channel is garbage collected, output channels can continue to receive values until they reach the end of the buffer, at which point receive will throw a NoInChanError. Alternatively, the GHC RTS may also throw a BlockedIndefinitelyOnSTM exception. For example:

(i, o) <- LC.new 64
LC.send i 1

m1 <- LC.receive o
assertM (m1 == 1)         -- receive the 1

m2 <- LC.receive o        -- throws NoInChanError or BlockedIndefinitelyOnSTM

Benchmarks

This section shows the results of time and space benchmarks that compare lossy-chan with various other channels implementations:

• The base benchmark uses Control.Concurrent.Chan.
• The stm benchmark uses Control.Concurrent.STM.TChan.
• The unagi-chan benchmark uses Control.Concurrent.Chan.Unagi.
• The lossy-chan-N benchmarks use Control.Concurrent.LossyChan with buffer size N.

The benchmark itself was adapted from the unagi-chan's benchmark, and consists of some number of sender threads, each of which sends 10,000 messages, and some number of receiver threads, each of which tries to receive 10,000 messages. Since lossy-chan channels may lose some messages, receiver threads terminate when they catch a NoInChanError or BlockedIndefinitelyOnSTM exception.

This isn't a fair comparison, since none of the other channel implementations is lossy. However, it should give you some idea of the performance and memory usage characteristics of lossy-chan.

Time

The time benchmark, created using criterion, shows that a lossy-chan channel is roughly as fast as an unagi-chan channel, and both are significantly faster than the base and stm channels. Moreover, the buffer size doesn't appear to significanly affect the performance of a lossy-chan channel.

Space

The space benchmark, created using weigh, shows that a lossy-chan channel has much lower maximum residency when compared to the other channel implementations, and that its maximum residency scales with the buffer size. This is expected from the use of a ring buffer.