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?
Simon
| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Ben
| Gamari
| Sent: 17 January 2016 19:55
| To: Alan & Kim Zimmerman ; ghc-devs@haskell.org
| Subject: Re: Multiple GHC sessions
|
| Alan & Kim Zimmerman writes:
|
| > 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, ....
| >
| This isn't the only global state had by the linker; have a look at
| rts/Linker.c. Unfortunately this would take a fair amount of work to
| resolve. The easiest solution here would probably be to put a lock
| around the linker and have all sessions in a process use the same
| linker.
|
| > compiler/main/StaticFlags.hs:94:GLOBAL_VAR(v_opt_C, ....
| > compiler/main/StaticFlags.hs:95:GLOBAL_VAR(v_opt_C_ready, ....
| >
| We've been meaning to get rid of the remaining static flags for quite
| some time.
|
| I was a bit surprised to find that opt_NoStateHack is static. This is
| a bit of an ugly one: the only user is a test in Id.isStateHackType
| which is buried inside several layers [1] of pure predicates that have
| no DynFlags. It would be a shame to pass a DynFlags through all of
| these calls just to support the state hack (which we threaten drop
| about once every six months).
|
| One option, of course, would be to merge all of the static flags into
| DynFlags and rework their users to use unsafeGlobalDynFlags.
|
| [1] One particular callpath is,
|
| Id.isStateHackType
| Id.typeOneShot
| CoreArity.typeArity
| CoreArity.exprArity
| CorePrep.rhsToBody
| CorePrep.cpeBody
|
|
| >
| compiler/main/DynFlags.hs:4453:GLOBAL_VAR(v_unsafeGlobalDynFlags,....
| >
| The principle user of this is Outputable, which uses it to provide
| DynFlags for pprTrace and friends. As you say, these are rather
| special cases and it's probably fine if they behave a bit funky in the
| case of more than one session in a process.
|
| > ghc/GHCi/UI.hs:149:GLOBAL_VAR(macros_ref,....
| >
| It is completely unclear why this is global at all. It seems like it
| would fit just fine in the GHCi monad. I've opened D1789 doing exactly
| this.
|
| There may be other global state that I'm not thinking of, but if this
| is everything then it seems quite possible to fix this up for 8.2.
|
| Cheers,
|
| - Ben
