Closable, fair, single-wakeup channel type that avoids 0 reader space leaks.
|Version on this page:||0.2.1.2|
|LTS Haskell 19.27:||0.2.1.2@rev:1|
|Stackage Nightly 2022-09-30:||0.2.1.2@rev:1|
|Latest on Hackage:||0.2.1.2@rev:1|
BroadcastChan: Closable, fair, single-wakeup, broadcast channels
A closable, fair, single-wakeup channel that avoids the 0 reader space leak
Control.Concurrent.Chan from base suffers from.
Chan type from
Control.Concurrent.Chan consists of both a read and
write end combined into a single value. This means there is always at least 1
read end for a
Chan, which keeps any values written to it alive. This is a
problem for applications/libraries that want to have a channel that can have
Suppose we have an library that produces events and we want to let users
register to receive events. If we use a channel and write all events to it, we
would like to drop and garbage collect any events that take place when there
are 0 listeners. The always present read end of
Chan from base makes this
impossible. We end up with a
Chan that forever accumulates more and more
events that will never get removed, resulting in a memory leak.
BroadcastChan splits channels into separate read and write ends. Any message
written to a a channel with no existing read end is immediately dropped so it
can be garbage collected. Once a read end is created, all messages written to
the channel will be accessible to that read end.
Once all read ends for a channel have disappeared and been garbage collected, the channel will return to dropping messages as soon as they are written.
Why should I use
BroadcastChanhas no 0 reader space leak,
BroadcastChanhas comparable or better performance.
Why should I use
BroadcastChan over various (closable) STM channels?
BroadcastChanperforms better under contention.
- Update bounds for GHC 9.0 and 9.2.
- Hacky fix of a tricky race condition #3.
- Updated imports to support
BroadcastChan.Extrato support thread related resource management. This is required to fix
broadcast-chan-conduit’s use of
- GHC 8.6/MonadFail compatibility fix
- Loosen STM bounds for new stackage release.
- Ditch GHC 7.6.3 support.
- Complete rework to be actually practical.
- Switched to standalone module hierarchy.
- Added functionality for parallel tasks.
- Add module which uses exceptions, instead of results to signal failure.