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-boun...@haskell.org] On Behalf Of Ben | Gamari | Sent: 17 January 2016 19:55 | To: Alan & Kim Zimmerman <alan.z...@gmail.com>; ghc-devs@haskell.org | Subject: Re: Multiple GHC sessions | | Alan & Kim Zimmerman <alan.z...@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 | 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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs