A do-nothing filter that accepts all messages (i.e., returns Keep for any input).

A filter that takes a Closure (Message -> Process FilterResult) holding the filter function and applies it remotely (i.e., in the mailbox's own managed process).

Instructs the mailbox to send a Delivery as soon as any mail is available, or immediately (if the buffer already contains data).

NB: signals are only delivered to the mailbox's owning process.

Start a mailbox for the calling process.

create = getSelfPid >>= start

Instructs the mailbox to deliver all pending messages to the owner.

Monitor a mailbox.

Instructs the mailbox to send a NewMail signal as soon as any mail is available for delivery. Once the signal is sent, it will not be resent, even when further mail arrives, until notify is called again.

NB: signals are only delivered to the mailbox's owning process.

Alters the mailbox's limit - this might cause messages to be dropped!

Start a mailbox for the supplied ProcessId.

start = spawnLocal $ run

As startMailbox, but suitable for use in supervisor child specs.

See Control.Distributed.Process.Supervisor

Obtain statistics (from/to anywhere) about a mailbox.

Describes the different types of buffer.

Mail delivery.

Represents the maximum number of messages the internal buffer can hold.

Opaque handle to a mailbox.

Bundle of statistics data, available on request via the mailboxStats API call.

Marker message indicating to the owning process that mail has arrived.

Bind the calling process to the given broadcast exchange. For each Message the exchange receives, only the payload will be sent to the calling process' mailbox.

Example:

(producer) > post ex Hello

(consumer) > bindToBroadcaster ex > expect >>= liftIO . putStrLn

Create a binding to the given broadcast exchange for the calling process and return an InputStream that can be used in the expect and receiveWait family of messaging primitives. This form of client interaction helps avoid cluttering the caller's mailbox with Message data, since the InputChannel provides a separate input stream (in a similar fashion to a typed channel). Example:

is <- broadcastClient ex
msg <- receiveWait [ matchInputStream is ]
handleMessage (payload msg)

Start a new broadcast exchange and return a handle to the exchange.

The ExchangeType of a broadcast exchange. Can be combined with the startSupervisedRef and startSupervised APIs.

Utility for custom exchange type authors - evaluates a set of primitive message handlers from left to right, returning the first which evaluates to Just a, or the initial e value if all the handlers yield Nothing.

Sends an arbitrary Serializable datum to an exchange, for use as a configuration change - see configureEx for details.

Utility for creating a Message datum from its key, headers and payload.

Posts an arbitrary Serializable datum to an exchange. The raw datum is wrapped in the Message data type, with its key set to "" and its headers to [].

Posts a Message to an exchange.

Starts an exchange process with the given ExchangeType.

Starts an exchange as part of a supervision tree.

Example: > childSpec = toChildStart $ startSupervisedRef exType

Add a binding (for the calling process) to a headerContentRouter exchange.

Add a binding (for the calling process) to a messageKeyRouter exchange.

A router that matches on a specific (named) header. To bind a client Process to such an exchange, use the bindHeader function.

A router that matches on a Message key. To bind a client Process to such an exchange, use the bindKey function.

Send a Serializable message to the supplied Exchange. The given datum will be converted to a Message, with the key set to "" and the headers to [].

The routing behaviour will be dependent on the choice of BindingSelector given when initialising the router.

Send a Message to the supplied Exchange. The routing behaviour will be dependent on the choice of BindingSelector given when initialising the router.

Defines a router exchange. The BindingSelector is used to construct a binding (i.e., an instance of the Bindable type k) for each incoming Message. Such bindings are matched against bindings stored in the exchange. Clients of a router exchange are identified by a binding, mapped to one or more ProcessIds.

The format of the bindings, nature of their storage and mechanism for submitting new bindings is implementation dependent (i.e., will vary by exchange type). For example, the messageKeyRouter and headerContentRouter implementations both use the Binding data type, which can represent a Message key or a HeaderName and content. As with all custom exchange types, bindings should be submitted by evaluating configureExchange with a suitable data type.

Defines a router that can be used in a supervision tree.

Opaque handle to an exchange.

Different exchange types are defined using record syntax. The configureEx and routeEx API functions are called during the exchange lifecycle when incoming traffic arrives. Configuration messages are completely arbitrary types and the exchange type author is entirely responsible for decoding them. Messages posted to the exchange (see the Message data type) are passed to the routeEx API function along with the exchange type's own internal state. Both API functions return a new (potentially updated) state and run in the Process monad.

Messages sent to an exchange can optionally provide a routing key and a list of (key, value) headers in addition to the underlying payload.

Things that can be used as binding keys in a router.

The binding key used by the built-in key and header based routers.

Used to convert a Message into a Bindable routing key.

Given to a router to indicate whether clients should receive Message payloads only, or the whole Message object itself.