I've answered all these questions (I hope) in the form of new Notes and signposts, please feel free to comment on this diff: https://phabricator.haskell.org/D2358. I'm happy to add more if needs be.
On 22 June 2016 at 16:39, Richard Eisenberg <[email protected]> wrote: > > 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
