On Jun 22, 2016, at 10:38 AM, Simon Marlow <[email protected]> wrote:
> Thanks for the feedback Richard. It's helpful to know which parts of the > implementation you found non-obvious. I will write some more Notes, but > first: I think what would help most is a place that describes the little state machine that's going on here: the startTH / runTH / finishTH cycle, with possible callbacks in between. All RPC calls are blocking, yes? That certainly simplifies the matter. In the state machine, I think it would help to see clearly what causes the state transition (e.g. splice encountered during renaming, reify call made during splicing) and where the code is located (both source file/function and client vs server). There's just a bunch of moving parts here spread across a number of files and two processes. > > * On why we need a RemoteRef of an IORef - because the IORef lives on the > server, so GHC has a RemoteRef to it. Did you see Note [External GHCi > pointers] in compiler/ghci/GHCi.hs? Does that help? Somewhat. So the server is sending a pointer (the IORef) to the client? Presumably this pointer is only usable on the server, so the client just ends up sending it back at some point. From the client's point of view, it's just getting an opaque key that only the server can decode. Perhaps this would all become clearer with the overall map. > Should I xref it from somewhere else? Perhaps from libraries/ghci/GHCi/RemoteTypes.hs, on the declaration of RemoteRef. Thanks! Richard _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
