broadcast-chan: Closable, fair, single-wakeup channel type that avoids 0 reader space leaks.

[ bsd3, library, system ] [ Propose Tags ]

WARNING: While the code in this library should be fairly stable and production, the API is something I'm still working on. API changes will follow the PVP, but expect breaking API changes in future versions!

A closable, fair, single-wakeup channel that avoids the 0 reader space leak that Control.Concurrent.Chan from base suffers from.

The 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 zero listeners.

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 BroadcastChan over Control.Concurrent.Chan?

Why should I use BroadcastChan over various (closable) STM channels?


[Skip to Readme]

Flags

Manual Flags

NameDescriptionDefault
sync

Benchmarks synchronisation primitives used in main benchmark.

Disabled
threaded

Run benchmarks with threaded backend.

Enabled

Use -f <flag> to enable a flag, or -f -<flag> to disable that flag. More info

Downloads

Note: This package has metadata revisions in the cabal description newer than included in the tarball. To unpack the package including the revisions, use 'cabal get'.

Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees

Candidates

  • No Candidates
Versions [RSS] 0.1.0, 0.1.1, 0.2.0, 0.2.0.1, 0.2.0.2, 0.2.1, 0.2.1.1, 0.2.1.2
Change log CHANGELOG.md
Dependencies base (>=4.7 && <4.12), unliftio-core (>=0.1.1 && <0.2) [details]
License BSD-3-Clause
Copyright Copyright © 2014-2018 Merijn Verstraaten
Author Merijn Verstraaten
Maintainer Merijn Verstraaten <merijn@inconsistent.nl>
Revised Revision 2 made by HerbertValerioRiedel at 2018-10-02T09:03:30Z
Category System
Home page https://github.com/merijn/broadcast-chan
Bug tracker https://github.com/merijn/broadcast-chan/issues
Source repo head: git clone ssh://github.com:merijn/broadcast-chan.git
head: hg clone https://bitbucket.org/merijnv/broadcast-chan
Uploaded by MerijnVerstraaten at 2018-09-24T14:27:09Z
Distributions Arch:0.2.1.2, Debian:0.2.1.1, LTSHaskell:0.2.1.2, NixOS:0.2.1.2
Reverse Dependencies 7 direct, 0 indirect [details]
Downloads 6566 total (45 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs uploaded by user
Build status unknown [no reports yet]

Readme for broadcast-chan-0.2.0.1

[back to package description]

BroadcastChan: Closable, fair, single-wakeup, broadcast channels

BSD3 Hackage Stackage Build Status

A closable, fair, single-wakeup channel that avoids the 0 reader space leak that Control.Concurrent.Chan from base suffers from.

The 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 zero listeners.

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 BroadcastChan over Control.Concurrent.Chan?

  • BroadcastChan is closable,
  • BroadcastChan has no 0 reader space leak,
  • BroadcastChan has comparable or better performance.

Why should I use BroadcastChan over various (closable) STM channels?

  • BroadcastChan is single-wakeup,
  • BroadcastChan is fair,
  • BroadcastChan performs better under contention.