Hoogle Search
Within LTS Haskell 24.52 (ghc-9.10.3)
Note that Stackage only displays results for the latest LTS and Nightly snapshot. Learn more.
type
DeferredCallHandler s a b = CallRef b -> CallHandler s a bdistributed-process-client-server Control.Distributed.Process.ManagedProcess An expression used to handle a call message where the reply is deferred via the CallRef
type
StatelessCallHandler s a b = CallRef b -> a -> Reply b sdistributed-process-client-server Control.Distributed.Process.ManagedProcess An expression used to handle a call message ignoring server state
call :: (Addressable s, Serializable a, Serializable b) => s -> a -> Process bdistributed-process-client-server Control.Distributed.Process.ManagedProcess.Client Make a synchronous call - will block until a reply is received. The calling process will exit with ExitReason if the calls fails. NOTE: this function does not catch exceptions!
callAsync :: (Addressable s, Serializable a, Serializable b) => s -> a -> Process (Async b)distributed-process-client-server Control.Distributed.Process.ManagedProcess.Client Invokes call out of band, and returns an async handle.
callChan :: (Addressable s, Serializable a, Serializable b) => s -> a -> Process (ReceivePort b)distributed-process-client-server Control.Distributed.Process.ManagedProcess.Client 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).
callSTM :: Addressable s => s -> (a -> STM ()) -> STM b -> a -> Process (Either ExitReason b)distributed-process-client-server Control.Distributed.Process.ManagedProcess.Client Manages an rpc-style interaction with a server process, using STM actions to read/write data. The server process is monitored for the duration of the call. The stm write expression is passed the input, and the read expression is evaluated and the result given as Right b or Left ExitReason if a monitor signal is detected whilst waiting. Note that the caller will exit (with ExitOther String) if the server address is un-resolvable. A note about scheduling and timing guarantees (or lack thereof): It is not possibly to guarantee the contents of ExitReason in cases where this API fails due to server exits/crashes. We establish a monitor prior to evaluating the stm writer action, however monitor is asychronous and we've no way to know whether or not the scheduler will allow monitor establishment to proceed first, or the stm transaction. As a result, assuming that your server process can diefailexit on evaluating the read end of the STM write we perform here (and we assume this is very likely, since we apply no safety rules and do not even worry about serializing thunks passed from the client's thread), it is just as likely that in the case of failure you will see a reason such as ExitOther DiedUnknownId due to the server process crashing before the node controller can establish a monitor. As unpleasant as this is, there's little we can do about it without making false assumptions about the runtime. Cloud Haskell's semantics guarantee us only that we will see some monitor signal in the event of a failure here. To provide a more robust error handling, you can catch/trap failures in the server process and return a wrapper reponse datum here instead. This will still be subject to the failure modes described above in cases where the server process exits abnormally, but that will at least allow the caller to differentiate between expected and exceptional failure conditions.
-
distributed-process-client-server Control.Distributed.Process.ManagedProcess.Client 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.
flushPendingCalls :: Serializable b => TimeInterval -> (b -> Process b) -> Process (Maybe b)distributed-process-client-server Control.Distributed.Process.ManagedProcess.Client Attempt to flush out any pending call responses.
-
distributed-process-client-server Control.Distributed.Process.ManagedProcess.Client Safe version of call that returns information about the error if the operation fails. If the calling process dies (that is, forces itself to exit such that an exit signal arises with ExitOther String) then evaluation will return Left exitReason and the explanation will be stashed away as (ExitOther String). NOTE: this function does not catch exceptions! The safety of the name, comes from carefully handling situations in which the server dies while we're waiting for a reply. Notably, exit signals from other processes, kill signals, and both synchronous and asynchronous exceptions can still terminate the caller abruptly. To avoid this consider masking or evaluating within your own exception handling code.
syncCallChan :: (Addressable s, Serializable a, Serializable b) => s -> a -> Process bdistributed-process-client-server Control.Distributed.Process.ManagedProcess.Client A synchronous version of callChan.