>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, the other things needing a GHC session are loading a module as far as type checking, for error reporting. I know this gets complicated if there is FFI involved and the loading has to go via object file generation. Alan On Mon, Jan 18, 2016 at 12:53 PM, Ben Gamari <[email protected]> wrote: > Simon Peyton Jones <[email protected]> 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 > GLOBAL_VAR. In fact, it arguably makes a fair bit of sense for all > sessions to use the same linker state given that they are also sharing > an address space. > > The only issue that may require a bit of care is code unloading. > Consider that you have two sessions A and B, > > 1. A loads MyModule > 2. B loads MyModule > 3. They both use MyModule for a while > 4. A unloads MyModule > 5. B continues > 6. B unloads MyModule > > I suspect that things will work fine up to step 6 since we don't > actually unload code until the garbage collector has marked the it as > dead. That being said, I suspect you would see an error from unloadObj > upon attempting to unload the object the second time (and even then, the > error is merely a message on stderr). Note, however, that the above > conclusions have not been tested. > > Otherwise, it appears that things should behave fair well as the > PersistentLinkerState is already wrapped in an MVar which should > serve to serialize linker calls. > > Cheers, > > - Ben > _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
