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

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.

Describes the different types of buffer.

Mail delivery.

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

Opaque handle to a mailbox.

Monitor a mailbox.

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

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.

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

Start a mailbox for the calling process.

create = getSelfPid >>= start

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

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

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

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).

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

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

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.

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 [].

Opaque handle to an exchange.

Starts an exchange as part of a supervision tree.

Example: > childSpec = toChildStart $ startSupervisedRef exType

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.

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)

Starts an exchange process with the given ExchangeType.

Posts a Message to an exchange.

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

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

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

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

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.

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.

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.

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

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.

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

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.