Multiple GHC sessions
Alan & Kim Zimmerman
alan.zimm at gmail.com
Sun Jan 17 15:05:39 UTC 2016
Yes, but this solution is bypassing the problem by using remote execution.
My question is what could be done to make the remote execution
unnecessary, i.e addressing the "Right now" part.
Alan
On Sun, Jan 17, 2016 at 4:58 PM, Bartosz Nitka <niteria at gmail.com> wrote:
> From https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi:
> "We can have multiple instances of a GHC Session on the GHC API, each
> running TH and/or interpreted code. Right now this is not possible because
> the linker's state is global."
>
> Regards,
> Bartosz
>
> 2016-01-17 14:49 GMT+00:00 Alan & Kim Zimmerman <alan.zimm at gmail.com>:
>>
>> At the moment there are issues with having multiple GHC API sessions
>> in a single executable, which boil down to GHC having global
>> variables.
>>
>> A quick grep over the GHC sources shows the following instances
>>
>> compiler/ghci/Linker.hs:90:GLOBAL_VAR_M(v_PersistentLinkerState, ...
>> compiler/ghci/Linker.hs:91:GLOBAL_VAR(v_InitLinkerDone, ....
>>
>> compiler/main/StaticFlags.hs:94:GLOBAL_VAR(v_opt_C, ....
>> compiler/main/StaticFlags.hs:95:GLOBAL_VAR(v_opt_C_ready, ....
>>
>> compiler/main/DynFlags.hs:4453:GLOBAL_VAR(v_unsafeGlobalDynFlags,....
>>
>> ghc/GHCi/UI.hs:149:GLOBAL_VAR(macros_ref,....
>>
>> Of these the v_unsafeGlobalDynFlags can probably be ignored, as they
>> are intended to be used in very specific, limited circumstances only.
>>
>> So, would it be possible to create a structure housing the remaining
>> ones, and somehow make it possible to access these in some kind of
>> session? Or preferably get rid of them, or move them into existing
>> structures such as DynFlags.
>>
>> This is an exploratory email, more to get a handle on what has been
>> done/considered already in this space.
>>
>> The issue does have a major impact on tooling developers though.
>>
>> Regards
>> Alan
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
More information about the ghc-devs
mailing list