Multiple GHC sessions
Simon Peyton Jones
simonpj at microsoft.com
Mon Jan 18 10:10:40 UTC 2016
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?
| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ben
| Sent: 17 January 2016 19:55
| To: Alan & Kim Zimmerman <alan.zimm at gmail.com>; ghc-devs at haskell.org
| Subject: Re: Multiple GHC sessions
| Alan & Kim Zimmerman <alan.zimm at gmail.com> 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
| > 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  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.
|  One particular callpath is,
| 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
| 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.
| - Ben
More information about the ghc-devs