API for client interactions with the process

Send a control message over a ControlPort.

Send a signal instructing the process to terminate. The receive loop which manages the process mailbox will prioritise Shutdown signals higher than any other incoming messages, but the server might be busy (i.e., still in the process of excuting a handler) at the time of sending however, so the caller should not make any assumptions about the timeliness with which the shutdown signal will be handled. If responsiveness is important, a better approach might be to send an exit signal with Shutdown as the reason. An exit signal will interrupt any operation currently underway and force the running process to clean up and terminate.

Make a synchronous call - will block until a reply is received. The calling process will exit with ExitReason if the calls fails.

Safe version of call that returns information about the error if the operation fails. If an error occurs then the explanation will be will be stashed away as (ExitOther String).

Version of safeCall that returns Nothing if the operation fails. If you need information about *why* a call has failed then you should use safeCall or combine catchExit and call instead.

Make a synchronous call, but timeout and return Nothing if a reply is not received within the specified time interval.

If the result of the call is a failure (or the call was cancelled) then the calling process will exit, with the ExitReason given as the reason. If the call times out however, the semantics on the server side are undefined, i.e., the server may or may not successfully process the request and may (or may not) send a response at a later time. From the callers perspective, this is somewhat troublesome, since the call result cannot be decoded directly. In this case, the flushPendingCalls API may be used to attempt to receive the message later on, however this makes no attempt whatsoever to guarantee which call response will in fact be returned to the caller. In those semantics are unsuited to your application, you might choose to exit or die in case of a timeout, or alternatively, use the callAsync API and associated waitTimeout function (in the Async API), which takes a re-usable handle on which to wait (with timeouts) multiple times.

Invokes call out of band, and returns an async handle.

Sends a cast message to the server identified by server. The server will not send a response. Like Cloud Haskell's send primitive, cast is fully asynchronous and never fails - therefore casting to a non-existent (e.g., dead) server process will not generate an error.

Sends a channel message to the server and returns a ReceivePort on which the reponse can be delivered, if the server so chooses (i.e., the might ignore the request or crash).

A synchronous version of callChan.

A safe version of syncCallChan, which returns Left ExitReason if the call fails.