The broadcast-chan package

This is a package candidate release! Here you can preview how this package release will appear once published to the main package index (which can be accomplished via the 'maintain' link below). Please note that once a package has been published to the main package index it cannot be undone! Please consult the package uploading documentation for more information.

[maintain]

Warnings:

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]

Properties

Versions0.1.0, 0.1.1, 0.1.1
Change logCHANGELOG.md
Dependenciesbase (>=4.5 && <5) [details]
LicenseBSD3
CopyrightCopyright © 2014 Merijn Verstraaten
AuthorMerijn Verstraaten
MaintainerMerijn Verstraaten <merijn@inconsistent.nl>
CategorySystem
Home pagehttps://github.com/merijn/broadcast-chan
Bug trackerhttps://github.com/merijn/broadcast-chan/issues
Source repositoryhead: git clone ssh://github.com:merijn/broadcast-chan.git
head: hg clone https://bitbucket.org/merijnv/broadcast-chan
UploadedFri May 19 13:32:17 UTC 2017 by MerijnVerstraaten

Modules

[Index]

Flags

NameDescriptionDefaultType
benchmark

Benchmarks depend on an unreleased version of Criterion, making them unbuildable without sanboxes.

DisabledManual
sync

Benchmarks synchronisation primitives used in main benchmark.

DisabledManual
threaded

Run benchmarks with threaded backend.

EnabledManual

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

Downloads

Maintainers' corner

For package maintainers and hackage trustees


Readme for broadcast-chan-0.1.1

[back to package description]

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

Hackage 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?

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