|
Control.Concurrent.CHP.Channels.BroadcastReduce |
|
|
Description |
A module containing broadcast channels (one-to-many). Whereas a one-to-any
channel features one writer sending a single value to one (of many) readers, a
one-to-many channel features one writer sending the same value to many
readers. So a one-to-any channel involves claiming the channel-end to ensure
exclusivity, but a one-to-many channel involves enrolling on the channel-end
(subscribing) before it can engage in communication.
A communication on a one-to-many channel only takes place when the writer
and all readers currently enrolled agree to communicate. What happens when
the writer wants to communicate and no readers are enrolled was undefined
in versions 1.5.1 and earlier (the writer may block, or may communicate
happily to no-one). However, in version 1.6.0 onwards the semantics are
clear: a writer that communicates on a broadcast channel with no readers
involved will succeed immediately, communicating to no-one (i.e. the data
is lost). Similarly, a read from a reduce channel will immediately return
mempty when no writers are enrolled. It is possible to get into a state
of livelock (by repeatedly performing these instant communications) in
these sorts of situations.
This module also contains reduce channels (added in version 1.1.1). Because
in CHP channels must have the same type at both ends, we use the Monoid
type-class. It is important to be aware that the order of mappends will be
non-deterministic, and thus you should either use an mappend that is commutative
or code around this restruction.
For example, a common thing to do would be to use lists as the type for
reduce channels, make each writer write a single item list (but more is
possible), then use the list afterwards, but be aware that it is unordered.
If it is important to have an ordered list, make each writer write a pair
containing a (unique) index value and the real data, then sort by the index
value and discard it.
Since reduce channels were added after the initial library design, there
is a slight complication: it is not possible to use newChannel (and all
similar functions) with reduce channels because it is impossible to express
the Monoid constraint for the Channel instance. Instead, you must use manyToOneChannel
and manyToAnyChannel.
|
|
Synopsis |
|
|
|
Documentation |
|
|
The reading end of a broadcast channel. You must enroll on it before
you can read from it or poison it.
The Eq instance was added in version 1.4.0.
| Instances | |
|
|
data BroadcastChanout a | Source |
|
The writing end of a broadcast channel.
The Eq instance was added in version 1.4.0.
| Instances | |
|
|
|
|
|
|
|
|
|
|
|
Added in version 1.5.0.
In versions 1.5.0-1.6.0, the broadcast and reduce channels do not appear correctly
in the traces.
|
|
|
Added in version 1.5.0.
In versions 1.5.0-1.6.0, the broadcast and reduce channels do not appear correctly
in the traces.
|
|
|
The reading end of a reduce channel.
The Eq instance was added in version 1.4.0.
| Instances | |
|
|
|
The writing end of a reduce channel. You must enroll on it before
you can read from it or poison it.
The Eq instance was added in version 1.4.0.
| Instances | |
|
|
|
The reduce channel version of sameChannel.
This function was added in version 1.4.0.
|
|
|
|
|
|
|
|
|
|
|
Added in version 1.5.0.
In versions 1.5.0-1.6.0, the broadcast and reduce channels do not appear correctly
in the traces.
|
|
|
Added in version 1.5.0.
In versions 1.5.0-1.6.0, the broadcast and reduce channels do not appear correctly
in the traces.
|
|
Produced by Haddock version 2.4.2 |