Multiple GHC sessions
Alan & Kim Zimmerman
alan.zimm at gmail.com
Mon Jan 18 11:18:49 UTC 2016
>From a tool writer perspective I would be happy to have GHC/Linker
sessions be completely separate from each other. But I guess in
practical terms a shared address space needs to be managed, making
The external interpreter for GHCI effectively solves the actual
loading problem, the other things needing a GHC session are loading a
module as far as type checking, for error reporting. I know this gets
complicated if there is FFI involved and the loading has to go via
object file generation.
On Mon, Jan 18, 2016 at 12:53 PM, Ben Gamari <ben at smart-cactus.org> wrote:
> Simon Peyton Jones <simonpj at microsoft.com> writes:
>> I don't think the state-hack tail should wag the dog here. The nub of
>> the problem in practice is the shared linker state isn't it?
> I'm not sure; it's not clear to me what would break if the linker were
> used by more than one session at a time, even with the current
> GLOBAL_VAR. In fact, it arguably makes a fair bit of sense for all
> sessions to use the same linker state given that they are also sharing
> an address space.
> The only issue that may require a bit of care is code unloading.
> Consider that you have two sessions A and B,
> 1. A loads MyModule
> 2. B loads MyModule
> 3. They both use MyModule for a while
> 4. A unloads MyModule
> 5. B continues
> 6. B unloads MyModule
> I suspect that things will work fine up to step 6 since we don't
> actually unload code until the garbage collector has marked the it as
> dead. That being said, I suspect you would see an error from unloadObj
> upon attempting to unload the object the second time (and even then, the
> error is merely a message on stderr). Note, however, that the above
> conclusions have not been tested.
> Otherwise, it appears that things should behave fair well as the
> PersistentLinkerState is already wrapped in an MVar which should
> serve to serialize linker calls.
> - Ben
More information about the ghc-devs