Remote.Channel

This module provides typed channels, an alternative approach to interprocess messaging. Typed channels can be used in combination with or instead of the the untyped channels available in the Remote.Process module via send.

Basic typed channels

data SendPort a

A channel is a unidirectional communication pipeline with two ends: a sending port, and a receiving port. This is the sending port. A process holding this value can insert messages into the channel. SendPorts themselves can also be sent to other processes. The other side of the channel is the ReceivePort.

Instances

Typeable1 SendPort

Binary (SendPort a)

data ReceivePort a

A process holding a ReceivePort can extract messages from the channel, which we inserted by the holder(s) of the corresponding SendPort. Critically, ReceivePorts, unlike SendPorts, are not serializable. This means that you can only receive messages through a channel on the node on which the channel was created.

newChannel :: Serializable a => ProcessM (SendPort a, ReceivePort a)

Create a new channel, and returns both the SendPort and ReceivePort thereof.

sendChannel :: Serializable a => SendPort a -> a -> ProcessM ()

Inserts a new value into the channel.

receiveChannel :: Serializable a => ReceivePort a -> ProcessM a

Extract a value from the channel, in FIFO order.

Combined typed channels

data CombinedChannelAction b

combinedChannelAction :: Serializable a => ReceivePort a -> (a -> b) -> CombinedChannelAction b

Specifies a port and an adapter for combining ports via combinePortsBiased and combinePortsRR.

combinePortsBiased :: Serializable b => [CombinedChannelAction b] -> ProcessM (ReceivePort b)

This function lets us respond to messages on multiple channels by combining several ReceivePorts into one. The resulting port is the sum of the input ports, and will extract messages from all of them in FIFO order. The input ports are specified by combinedChannelAction, which also gives a converter function. After combining the underlying receive ports can still be used independently, as well. We provide two ways to combine ports, which differ bias they demonstrate in returning messages when more than one underlying channel is nonempty. combinePortsBiased will check ports in the order given by its argument, and so if the first channel always was a message waiting, it will. starve the other channels. The alternative is combinePortsRR.

combinePortsRR :: Serializable b => [CombinedChannelAction b] -> ProcessM (ReceivePort b)

See combinePortsBiased. This function differs from that one in that the order that the underlying ports are checked is rotated with each invocation, guaranteeing that, given enough invocations, every channel will have a chance to contribute a message.

mergePortsBiased :: Serializable a => [ReceivePort a] -> ProcessM (ReceivePort a)

Similar to combinePortsBiased, with the difference that the the underlying ports must be of the same type, and you don't have the opportunity to provide an adapter function.

mergePortsRR :: Serializable a => [ReceivePort a] -> ProcessM (ReceivePort a)

Similar to combinePortsRR, with the difference that the the underlying ports must be of the same type, and you don't have the opportunity to provide an adapter function.

Terminate a channel

terminateChannel :: Serializable a => ReceivePort a -> ProcessM ()

Terminate a channel. After calling this function, receiveChannel on that port (or on any combined port based on it) will either fail or block indefinitely, and sendChannel on the corresponding SendPort will fail. Any unread messages remaining in the channel will be lost.