Multiple GHC sessions

[Ben Gamari]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160117/2fd6ae08/attachment.sig>