GHC API: Using runGhc twice or from multiple threads?

Manuel M T Chakravarty chak at cse.unsw.edu.au
Sun Jan 26 12:21:13 UTC 2014


I should have thought of that. Thanks for the clarification.

Cheers,
Manuel

Simon Marlow <marlowsd at gmail.com>:
> On 24/01/14 01:38, Manuel M T Chakravarty wrote:
>> Simon Marlow <marlowsd at gmail.com>:
>>>> And what about this one:
>>>> 
>>>> main = do
>>>>    forkIO $ runGhc libdir $ do ...
>>>>    forkIO $ runGhc libdir $ do ...
>>> 
>>> The problem with this is the RTS linker, which is a single piece of shared global state.  We could actually fix that if it became important.  If you’re not running interpreted code, this should be fine (apart from the static flags issue mentioned above).
>> 
>> I’m curious, what is the issue with interpreted code? Does the interpreter store interpreter state in the RTS, which would get mixed up between the two instances?
>> 
>> If so, wouldn’t the same thing happen if I use forkIO in interpreted code?
> 
> It is the linker state that is shared, that is, the mapping from symbol names to object code addresses.  So you can certainly do concurrency in an interpreted program, but you can't load two different sets of object files into two instances of GHC running in separate threads.  This is true regardless of whether we're using the system linker or the RTS linker.  In the RTS linker case it's fixable easily enough, in the system linker case there's really only one global symbol table (populated by RTLD_GLOBAL) so I'm not sure whether there's a way around that.
> 
> Cheers,
> 	Simon
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs



More information about the ghc-devs mailing list