Multiple GHC sessions

[Alan & Kim Zimmerman]

>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
this impossible.

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.

Alan

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.
>
> Cheers,
>
> - Ben
>