On 18 January 2016 at 11:18, Alan & Kim Zimmerman
wrote:
> From a tool writer perspective I would be happy to have GHC/Linker
> sessions be completely separate from each other. But I guess in
> practical terms a shared address space needs to be managed, making
> this impossible.
>
> The external
>From a tool writer perspective I would be happy to have GHC/Linker
sessions be completely separate from each other. But I guess in
practical terms a shared address space needs to be managed, making
this impossible.
The external interpreter for GHCI effectively solves the actual
loading problem, t
Simon Peyton Jones writes:
> 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?
>
I'm not sure; it's not clear to me what would break if the linker were
used by more than one session at a time, even with the current
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.
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_Persist
Yes, but this solution is bypassing the problem by using remote execution.
My question is what could be done to make the remote execution
unnecessary, i.e addressing the "Right now" part.
Alan
On Sun, Jan 17, 2016 at 4:58 PM, Bartosz Nitka wrote:
> From https://ghc.haskell.org/trac/ghc/wiki/Rem
>From https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi:
"We can have multiple instances of a GHC Session on the GHC API, each
running TH and/or interpreted code. Right now this is not possible because
the linker's state is global."
Regards,
Bartosz
2016-01-17 14:49 GMT+00:00 Alan & Kim Zimmerman
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
