git.iko.soy/distributed-process
on master help sign in
More cleanup
5e9b583Edsko de Vries
distributed-process/src/Control/Distributed/Process.hs+17−43
@@ -36,35 +36,26 @@
36-- Peyton-Jones.
36-- Peyton-Jones.
37-- http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/remote.pdf
37-- http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/remote.pdf
38--
38--
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+--
39-- Some pointers to related documentation about Erlang, for comparison and
44-- Some pointers to related documentation about Erlang, for comparison and
40-- inspiration:
45-- inspiration:
41--
46--
42−-- [1] "Programming Distributed Erlang Applications: Pitfalls and Recipes",
47+-- [3] "Programming Distributed Erlang Applications: Pitfalls and Recipes",
43-- Hans Svensson and Lars-Ake Fredlund
48-- Hans Svensson and Lars-Ake Fredlund
44-- http://man.lupaworld.com/content/develop/p37-svensson.pdf
49-- 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"
46-- http://www.erlang.org/doc/reference_manual/processes.html#id82409
51-- http://www.erlang.org/doc/reference_manual/processes.html#id82409
47-- http://www.erlang.org/doc/reference_manual/expressions.html#send
52-- 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
49-- "If I send a message, is it guaranteed to reach the receiver?" of
54-- "If I send a message, is it guaranteed to reach the receiver?" of
50-- the Erlang FAQ
55-- the Erlang FAQ
51-- http://www.erlang.org/faq/academic.html
56-- 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
53-- http://erlang.org/pipermail/erlang-questions/2012-February/064767.html
58-- 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
68module Control.Distributed.Process
59module Control.Distributed.Process
69 ( -- * Basic cloud Haskell API
60 ( -- * Basic cloud Haskell API
70 ProcessId
61 ProcessId
@@ -700,32 +691,15 @@ payloadToId bss = let (bs1, bss') = BSS.splitAt 4 . BSS.concat $ bss
700 }
691 }
701 _ -> fail "payloadToId"
692 _ -> fail "payloadToId"
702
693
703−-- TODO: this was written before the change to the new semantics
704remoteProcessFailed :: LocalNode -> ProcessId -> IO ()
694remoteProcessFailed :: LocalNode -> ProcessId -> IO ()
705−remoteProcessFailed node them = liftIO $
695+remoteProcessFailed node them = do
706− modifyMVar_ (localState node) $ \st -> do
696+ -- [Unified: Table 9 rule node_disconnect]
707− sequence_ (st ^. monitorActionsFor them)
697+ let nid = Right (processNodeId them)
708− return (monitorActionsFor them ^= [] $ st)
698+ writeChan (localCtrlChan node) NCMsg
709−
699+ { ctrlMsgSender = nid
710−{-do
700+ , ctrlMsgSignal = Died nid DiedDisconnect
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− -}
701+ }
728−
702+
729createMessage :: Serializable a => a -> Message
703createMessage :: Serializable a => a -> Message
730createMessage a = Message (fingerprint a) (encode a)
704createMessage a = Message (fingerprint a) (encode a)
731
705