@@ -36,35 +36,26 @@
3636-- Peyton-Jones.
3737-- http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/remote.pdf
3838--
39+-- The precise semantics for message passing is based on
40+--
41+-- [2] "A Unified Semantics for Future Erlang", Hans Svensson, Lars-Ake Fredlund
42+-- and Clara Benac Earle (not freely available online, unfortunately)
43+--
3944-- Some pointers to related documentation about Erlang, for comparison and
4045-- inspiration:
4146--
42−-- [1] "Programming Distributed Erlang Applications: Pitfalls and Recipes",
47+-- [3] "Programming Distributed Erlang Applications: Pitfalls and Recipes",
4348-- Hans Svensson and Lars-Ake Fredlund
4449-- http://man.lupaworld.com/content/develop/p37-svensson.pdf
45−-- [2] The Erlang manual, sections "Message Sending" and "Send"
50+-- [4] The Erlang manual, sections "Message Sending" and "Send"
4651-- http://www.erlang.org/doc/reference_manual/processes.html#id82409
4752-- http://www.erlang.org/doc/reference_manual/expressions.html#send
48−-- [3] Questions "Is the order of message reception guaranteed?" and
53+-- [5] Questions "Is the order of message reception guaranteed?" and
4954-- "If I send a message, is it guaranteed to reach the receiver?" of
5055-- the Erlang FAQ
5156-- http://www.erlang.org/faq/academic.html
52−-- [4] "Delivery of Messages", post on erlang-questions
57+-- [6] "Delivery of Messages", post on erlang-questions
5358-- http://erlang.org/pipermail/erlang-questions/2012-February/064767.html
54−--
55−-- TODOs:
56−--
57−-- 1. Central MonitorAction mapping, so that we can efficiently execute monitor
58−-- actions from Network.Transport.receive-ing thread.
59−-- 2. Access this mapping from send too, because we cannot rely on
60−-- EventConnectionLost (although it so happens that with the TCP transport
61−-- we can).
62−-- 3. Modify EvenConnectionLost to have Maybe EndPointAddress
63−-- 4. Change in API? (you can register multiple monitors, they get MonitorIds.
64−-- to unregister, to provide the monitor ID -- if we do, unregistering the
65−-- same ID multiple times is idempotent)
66−-- 5. You get precisely one notification per monitor
67−-- 6. When a connection is already broken, monitor notifies immediately
6859module Control.Distributed.Process
6960 ( -- * Basic cloud Haskell API
7061 ProcessId
@@ -700,32 +691,15 @@ payloadToId bss = let (bs1, bss') = BSS.splitAt 4 . BSS.concat $ bss
700691 }
701692 _ -> fail "payloadToId"
702693
703−-- TODO: this was written before the change to the new semantics
704694remoteProcessFailed :: LocalNode -> ProcessId -> IO ()
705−remoteProcessFailed node them = liftIO $
706− modifyMVar_ (localState node) $ \st -> do
707− sequence_ (st ^. monitorActionsFor them)
708− return (monitorActionsFor them ^= [] $ st)
709−
710−{-do
711− proc <- ask
712− let ourState = processState proc
713− -- We only execute monitor actions once
714− action <- liftIO . modifyMVar ourState $ \st ->
715− return (monitorActionFor them ^= Nothing $ st, st ^. monitorActionFor them)
716− let err = ProcessMonitorException them SrNoPing
717− liftIO $ case action of
718− Just MaMonitor ->
719− -- TODO: can/should we avoid this encoding/decoding?
720− enqueue (processQueue proc) $ createMessage err
721− Just MaLink ->
722− throwIO err
723− Just MaLinkError ->
724− throwIO err
725− Nothing ->
726− return ()
727− -}
728−
695+remoteProcessFailed node them = do
696+ -- [Unified: Table 9 rule node_disconnect]
697+ let nid = Right (processNodeId them)
698+ writeChan (localCtrlChan node) NCMsg
699+ { ctrlMsgSender = nid
700+ , ctrlMsgSignal = Died nid DiedDisconnect
701+ }
702+
729703createMessage :: Serializable a => a -> Message
730704createMessage a = Message (fingerprint a) (encode a)
731705