<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 18 January 2016 at 11:18, Alan & Kim Zimmerman <span dir="ltr"><<a href="mailto:alan.zimm@gmail.com" target="_blank">alan.zimm@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">From a tool writer perspective I would be happy to have GHC/Linker<br>
sessions be completely separate from each other. But I guess in<br>
practical terms a shared address space needs to be managed, making<br>
this impossible.<br>
<br>
The external interpreter for GHCI effectively solves the actual<br>
loading problem, the other things needing a GHC session are loading a<br>
module as far as type checking, for error reporting. I know this gets<br>
complicated if there is FFI involved and the loading has to go via<br>
object file generation.<span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div>Yes, I think -fexternal-interpreter is the basis of the right solution here.  You do also need to move the 
PersistentLinkerState to HscEnv, but that should be a fairly 
straightforward refactoring.  (actually I almost did this as part of the
 remote GHCi work, but some of the comments next to 
PersistentLinkerState suggested that there might be some real use cases 
for having the linker state be shared between multiple sessions, so I 
decided not to attack that problem right away.)<br></div><div> <br></div><div>Cheers,<br></div><div>Simon<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><font color="#888888">
Alan<br>
</font></span><div class=""><div class="h5"><br>
On Mon, Jan 18, 2016 at 12:53 PM, Ben Gamari <<a href="mailto:ben@smart-cactus.org">ben@smart-cactus.org</a>> wrote:<br>
> Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>> writes:<br>
><br>
>> I don't think the state-hack tail should wag the dog here. The nub of<br>
>> the problem in practice is the shared linker state isn't it?<br>
>><br>
> I'm not sure; it's not clear to me what would break if the linker were<br>
> used by more than one session at a time, even with the current<br>
> GLOBAL_VAR. In fact, it arguably makes a fair bit of sense for all<br>
> sessions to use the same linker state given that they are also sharing<br>
> an address space.<br>
><br>
> The only issue that may require a bit of care is code unloading.<br>
> Consider that you have two sessions A and B,<br>
><br>
>   1. A loads MyModule<br>
>   2. B loads MyModule<br>
>   3. They both use MyModule for a while<br>
>   4. A unloads MyModule<br>
>   5. B continues<br>
>   6. B unloads MyModule<br>
><br>
> I suspect that things will work fine up to step 6 since we don't<br>
> actually unload code until the garbage collector has marked the it as<br>
> dead. That being said, I suspect you would see an error from unloadObj<br>
> upon attempting to unload the object the second time (and even then, the<br>
> error is merely a message on stderr). Note, however, that the above<br>
> conclusions have not been tested.<br>
><br>
> Otherwise, it appears that things should behave fair well as the<br>
> PersistentLinkerState is already wrapped in an MVar which should<br>
> serve to serialize linker calls.<br>
><br>
> Cheers,<br>
><br>
> - Ben<br>
><br>
</div></div><div class=""><div class="h5">_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div></div>