Process identifier

Node identifier

The Cloud Haskell Process type

A send port is identified by a SendPortId.

You cannot send directly to a SendPortId; instead, use newChan to create a SendPort.

The ID of the node the process is running on

The ID of the process that will receive messages sent on this port

Lift a computation from the IO monad.

Send a message

Wait for a message of a specific type

Like expect but with a timeout

The receive end of a typed channel (not serializable)

Note that ReceivePort implements Functor, Applicative, Alternative and Monad. This is especially useful when merging receive ports.

The send send of a typed channel (serializable)

The (unique) ID of this send port

Create a new typed channel

Send a message on a typed channel

Wait for a message on a typed channel

Like receiveChan but with a timeout. If the timeout is 0, do a non-blocking check for a message.

Merge a list of typed channels.

The result port is left-biased: if there are messages available on more than one port, the first available message is returned.

Like mergePortsBiased, but with a round-robin scheduler (rather than left-biased)

Opaque type used in receiveWait and receiveTimeout

Test the matches in order against each message in the queue

Like receiveWait but with a timeout.

If the timeout is zero do a non-blocking check for matching messages. A non-zero timeout is applied only when waiting for incoming messages (that is, after we have checked the messages that are already in the mailbox).

Match against any message of the right type

Match against any message of the right type that satisfies a predicate

Remove any message from the queue

Match against an arbitrary message

Spawn a process

For more information about Closure, see Control.Distributed.Process.Closure.

See also call.

Run a process remotely and wait for it to reply

We monitor the remote process: if it dies before it can send a reply, we die too.

For more information about Static, SerializableDict, and Closure, see Control.Distributed.Process.Closure.

See also spawn.

Terminate (throws a ProcessTerminationException)

Thrown by terminate

Exception thrown when a process attempts to register a process under an already-registered name or to unregister a name that hasn't been registered

SpawnRef are used to return pids of spawned processes

Our own process ID

Get the node ID of our local node

Link to a remote process (asynchronous)

When process A links to process B (that is, process A calls link pidB) then an asynchronous exception will be thrown to process A when process B terminates (normally or abnormally), or when process A gets disconnected from process B. Although it is technically possible to catch these exceptions, chances are if you find yourself trying to do so you should probably be using monitor rather than link. In particular, code such as

 link pidB   -- Link to process B
 expect      -- Wait for a message from process B
 unlink pidB -- Unlink again

doesn't quite do what one might expect: if process B sends a message to process A, and subsequently terminates, then process A might or might not be terminated too, depending on whether the exception is thrown before or after the unlink (i.e., this code has a race condition).

Linking is all-or-nothing: A is either linked to B, or it's not. A second call to link has no effect.

Note that link provides unidirectional linking (see spawnSupervised). Linking makes no distinction between normal and abnormal termination of the remote process.

Link to a node (asynchronous)

Link to a channel (asynchronous)

Remove a link

This is synchronous in the sense that once it returns you are guaranteed that no exception will be raised if the remote process dies. However, it is asynchronous in the sense that we do not wait for a response from the remote node.

Remove a node link

This has the same synchronous/asynchronous nature as unlink.

Remove a channel (send port) link

This has the same synchronous/asynchronous nature as unlink.

Monitor another process (asynchronous)

When process A monitors process B (that is, process A calls monitor pidB) then process A will receive a ProcessMonitorNotification when process B terminates (normally or abnormally), or when process A gets disconnected from process B. You receive this message like any other (using expect); the notification includes a reason (DiedNormal, DiedException, DiedDisconnect, etc.).

Every call to monitor returns a new monitor reference MonitorRef; if multiple monitors are set up, multiple notifications will be delivered and monitors can be disabled individually using unmonitor.

Monitor a node (asynchronous)

Monitor a typed channel (asynchronous)

Remove a monitor

This has the same synchronous/asynchronous nature as unlink.

Exceptions thrown when a linked process dies

Exception thrown when a linked node dies

Exception thrown when a linked channel (port) dies

MonitorRef is opaque for regular Cloud Haskell processes

Message sent by process monitors

Message sent by node monitors

Message sent by channel (port) monitors

Why did a process die?

A closure is a static value and an encoded environment

A static value. Static is opaque; see staticLabel and staticApply.

Resolve a static value

Resolve a closure

Runtime dictionary for unstatic lookups

Log a string

say message sends a message (time, pid of the current process, message) to the process registered as logger. By default, this process simply sends the string to stderr. Individual Cloud Haskell backends might replace this with a different logger process, however.

Register a process with the local registry (asynchronous). This version will wait until a response is gotten from the management process. The name must not already be registered. The process need not be on this node. A bad registration will result in a ProcessRegistrationException

The process to be registered does not have to be local itself.

Like register, but will replace an existing registration. The name must already be registered.

Remove a process from the local registry (asynchronous). This version will wait until a response is gotten from the management process. The name must already be registered.

Query the local process registry

Named send to a process in the local registry (asynchronous)

Register a process with a remote registry (asynchronous).

The process to be registered does not have to live on the same remote node. Reply wil come in the form of a RegisterReply message

See comments in whereisRemoteAsync

Remove a process from a remote registry (asynchronous).

Reply wil come in the form of a RegisterReply message

See comments in whereisRemoteAsync

Query a remote process registry (asynchronous)

Reply will come in the form of a WhereIsReply message.

There is currently no synchronous version of whereisRemoteAsync: if you implement one yourself, be sure to take into account that the remote node might die or get disconnect before it can respond (i.e. you should use monitorNode and take appropriate action when you receive a NodeMonitorNotification).

Named send to a process in a remote registry (asynchronous)

(Asynchronous) reply from whereis

Lift catch

Lift mask

Lift onException

Lift bracket

Lift bracket_

Lift finally

Asynchronous version of spawn

(spawn is defined in terms of spawnAsync and expect)

Spawn a child process, have the child link to the parent and the parent monitor the child

Spawn a process and link to it

Note that this is just the sequential composition of spawn and link. (The Unified semantics that underlies Cloud Haskell does not even support a synchronous link operation)

Like spawnLink, but monitor the spawned process

Spawn a new process, supplying it with a new ReceivePort and return the corresponding SendPort.

(Asynchronius) reply from spawn

Spawn a process on the local node

Create a new typed channel, spawn a process on the local node, passing it the receive port, and return the send port

Cloud Haskell provides the illusion of connection-less, reliable, ordered message passing. However, when network connections get disrupted this illusion cannot always be maintained. Once a network connection breaks (even temporarily) no further communication on that connection will be possible. For example, if process A sends a message to process B, and A is then notified (by monitor notification) that it got disconnected from B, A will not be able to send any further messages to B, unless A explicitly indicates that it is acceptable to attempt to reconnect to B using the Cloud Haskell reconnect primitive.

Importantly, when A calls reconnect it acknowledges that some messages to B might have been lost. For instance, if A sends messages m1 and m2 to B, then receives a monitor notification that its connection to B has been lost, calls reconnect and then sends m3, it is possible that B will receive m1 and m3 but not m2.

Note that reconnect does not mean reconnect now but rather /it is okay to attempt to reconnect on the next send/. In particular, if no further communication attempts are made to B then A can use reconnect to clean up its connection to B.

Reconnect to a sendport. See reconnect for more information.