Multiple GHC sessions

[Ben Gamari]

Simon Peyton Jones <simonpj at microsoft.com> 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

-------------- 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/20160118/232b08dd/attachment.sig>