I should have thought of that. Thanks for the clarification. Cheers, Manuel
Simon Marlow <[email protected]>: > On 24/01/14 01:38, Manuel M T Chakravarty wrote: >> Simon Marlow <[email protected]>: >>>> 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 > [email protected] > http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
