Multiple GHC sessions

[Simon Peyton Jones]

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 at haskell.org] On Behalf Of Ben
|  Gamari
|  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
|  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