writeChannel functions are the standard way to communicate
on a channel. These functions wait for the other party in the communication
to arrive, then exchange the data, then complete. In pseudo-code, the semantics
are like this when two parties (shown here as two columns) communicate:
do sync sync x <- return y done done
Further options are offered by the
which allow either side to perform additional (so-called extended) actions during the communication.
The semantics when both sides are performing extended actions are:
do sync sync y <- extWriteAction x <- return y x' <- extReadAction x done done done return x'
- class ReadableChannel chanEnd where
- class WriteableChannel chanEnd where
- writeValue :: WriteableChannel chanEnd => a -> chanEnd a -> CHP ()
- writeChannelStrict :: (NFData a, WriteableChannel chanEnd) => chanEnd a -> a -> CHP ()
A class indicating that a channel can be read from.
Reads from the given reading channel-end
Performs an extended read from the channel, performing the given action before freeing the writer
A class indicating that a channel can be written to.
Writes from the given writing channel-end
Starts the communication, then performs the given extended action, then sends the result of that down the channel.
Like extWriteChannel, but allows a value to be returned from the inner action.
This function was added in version 1.4.0.
A useful synonym for
flip writeChannel. Especially useful with
so that instead of writing
claim output (flip writeChannel 6) you can write
claim output (writeValue 6).
Added in version 1.5.0.
A helper function that uses the parallel strategies library (see the paper: "Algorithm + Strategy = Parallelism", P.W. Trinder et al, JFP 8(1) 1998, http://www.macs.hw.ac.uk/~dsg/gph/papers/html/Strategies/strategies.html) to make sure that the value sent down a channel is strictly evaluated by the sender before transmission.
This is useful when you want to write worker processes that evaluate data and send it back to some "harvester" process. By default the values sent back may be unevaluated, and thus the harvester might end up doing the evaluation. If you use this function, the value is guaranteed to be completely evaluated before sending.
Added in version 1.0.2.