
On 12/07/2009 16:49, Daniel GorĂn wrote:
Hi
I'm trying to use the GHC API to have several instances of GHC's interpreter loaded simultaneously; each with its own loaded modules, etc. However, this doesn't seem to work well when two instances have loaded modules with the same name. I'm including the code of a small(ish) example of this at the end of the message.
The example launches two threads (with forkIO) and fires GHC in interpreted mode on each thread (with GHC.runGhc); then it sequentially loads file TestMain1.hs in the first and TestMain2.hs in the second one and finally tries to evaluate expression test1 defined in the first one followed by test2 defined in the second one. The output is:
#./Main 1: Load succeded 2: Load succeded 3: (1,2,3) 4: Main: During interactive linking, GHCi couldn't find the following symbol: Main_test1_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs@haskell.org
Main: thread blocked indefinitely #
The "thread blocked indefinitely" message is not important (comes from simplifying the original example). I tried this both in ghc 6.10.1 and ghc 6.11.20090607 with the same results.
Is this a known limitation? Or should I be doing it some other way?
Yes, it is a known limitation. It ought to be documented somewhere. There are two problems: 1. GHC is not thread-safe. There are some items of global state (the NameCache and the PackageInterfaceTable) that should be protected. It's not a trivial matter to do this - we had a hacky solution for the parallel compilation experiment we did a while back, but it wasn't finished. You could workaround this by using a mutex and only invoking GHC API operations in one thread at a time. 2. There is only one RTS linker with a single symbol table. This is the problem you ran into. There's no workaround that I'm aware of. Cheers, Simon