Re: Multiple GHC sessions

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 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 :

...

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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs