Ok, great. We are only loading object files from C code, not Haskell code -- we use the GHC API for that. And we're not using *anything* concurrently when it comes to GHC, so that should be okay too. I've been experimenting more with this and it seems to work okay :)
Will let you know if we come across any problems. Edsko On Tue, Nov 5, 2013 at 8:51 AM, Simon Marlow <[email protected]> wrote: > On 31/10/2013 18:06, Edsko de Vries wrote: >> >> Hi guys, >> >> We started experimenting with dynamically loading and unloading C >> object files (using the GHC API). I have a simple example with an >> object file exporting a single symbol "f"; I have two versions of the >> object file; in the first one, f is defined >> >> int f() { >> return 1234; >> } >> >> The second one uses the value "4321" instead. I can dynamically load >> and unload these object files (using "linkObj" and "unlinkObj" from >> "ObjLink"). I can load the first, dynamically compile some Haskell >> code that imports this symbol, then upload this object file and load >> the second, and as long as I make sure that the Haskell code gets >> recompiled (perhaps a relink step suffices, haven't experimented an >> awful lot yet) it can then interact with the second object file. > > > So you're loading C code using linkObj, and then compiling some Haskell code > that uses 'foreign import' to reference the C code? That *should* be fine, > but it's not a use-case that we have thought about. I certainly wouldn't > try to load Haskell code manually while also using the GHC API. > > The RTS linker isn't thread-safe, so be careful about using the GHC API and > calling linkObj etc. concurrently. > > >> All this is good news -- in fact, it is more than we had hoped for, >> because ghci does not allow dynamically unloading or loading any >> object files at all. Object files specified on the command line are >> handled in initDynLinker and the ghci top-level function doesn't even >> get to see them, and we cannot load object files from inside a ghci >> session. > > > Nobody asked for this, so we never implemented it :-) It ought to be > entirely reasonable to extend the GHC API to allow for loading and unloading > of foreign object files, and to expose that functionality in GHCi. > > Cheers, > Simon > > >> So that leads me to wonder: are there limitations that we should be >> aware of? Have I simply been lucky so far? >> >> Any points or suggestions for things to try would be appreciated, >> >> Edsko >> _______________________________________________ >> 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
