>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 <[email protected]>: > 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 > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
