GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?status=!closed&reporter=jcpetruzza&order=priority
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/query?status=!closed&reporter=jcpetruzza&order=priority
Trac 1.0.1
http://ghc.haskell.org/trac/ghc/ticket/3372
http://ghc.haskell.org/trac/ghc/ticket/3372#3372: Allow for multiple linker instancesTue, 14 Jul 2009 22:25:01 GMTjcpetruzza<p>
Right now there is only one RTS linker with a single symbol table.This means, for example, that one cannot have multiple instances of the GHC interpreter in the same process running simultaneously.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3372#changelog
http://ghc.haskell.org/trac/ghc/ticket/3373
http://ghc.haskell.org/trac/ghc/ticket/3373#3373: GHC API is not thread safeTue, 14 Jul 2009 22:31:26 GMTjcpetruzza<p>
There are some items of global state (the <tt>NameCache</tt> and the <tt>PackageInterfaceTable</tt>) that should be protected. One can workaround this by using a mutex and only invoking GHC API operations in one thread at a time.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3373#changelog
http://ghc.haskell.org/trac/ghc/ticket/4162
http://ghc.haskell.org/trac/ghc/ticket/4162#4162: GHC API messes up signal handlersWed, 30 Jun 2010 19:38:48 GMTjcpetruzza<p>
A side-effect of using the <tt>runGhc</tt> function is that some signal handlers are modified and not restored afterwards (see function <tt>initGhcMonad</tt>). In particular, the handler for <tt>SIGINT</tt> installed by ghc throws an exception to a thread stored in a global variable, which initially corresponds to the thread from which <tt>runGhc</tt> was run.
</p>
<p>
This is a particularly problematic for programs that wish to run ghc "in the background" on its own thread. For example, consider this code:
</p>
<pre class="wiki">import qualified GHC
import qualified MonadUtils as GHC
import qualified GHC.Paths as GHC
import Control.Concurrent ( forkIO, threadDelay )
main = do
putStrLn "waiting for 5 seconds..."
threadDelay $ 5 * 1000 * 1000
putStrLn "starting..."
forkIO $ GHC.runGhc (Just GHC.libdir) (GHC.liftIO $ putStrLn "hello")
putStrLn "waiting for 10 seconds"
threadDelay $ 10 * 1000 * 1000
putStrLn "exiting after final wait"
</pre><p>
One can interrupt this program with Ctrl-C during the first five seconds of execution only.
</p>
<p>
It is not clear to me how one can safely workaround this problem. For instance, one could manually restore the program's original handlers at the beginning of execution, that is, transform:
</p>
<pre class="wiki">runGhc action
</pre><p>
into something like this:
</p>
<pre class="wiki">runGhc $ (liftIO restoreProgramHandlers >> action)
</pre><p>
but I don't know if this is safe (i.e., what happens if ghc is run without its own handlers installed).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4162#changelog
http://ghc.haskell.org/trac/ghc/ticket/5316
http://ghc.haskell.org/trac/ghc/ticket/5316#5316: Orphan instances strike again: ghc rejects a program at first but will accept it if you repeat the same compilation commandMon, 11 Jul 2011 20:24:10 GMTjcpetruzza<p>
Consider these two modules (boiled down example from the checkers package):
</p>
<pre class="wiki">{-# LANGUAGE ScopedTypeVariables, FlexibleContexts #-}
module T1
where
import Test.QuickCheck
import Text.Show.Functions ()
f :: forall m a b. ( Arbitrary (a->b) ) => m (a,b) -> Property
f = const $ property (undefined :: (a->b) -> Bool)
</pre><pre class="wiki">module T2 where
import Control.Concurrent
g = threadDelay maxBound
</pre><p>
I see the following interaction:
</p>
<pre class="wiki">$ rm *hi *.o
$ ghc --make -c -O T1 T2
[1 of 2] Compiling T2 ( T2.hs, T2.o )
[2 of 2] Compiling T1 ( T1.hs, T1.o )
T1.hs:12:13:
Overlapping instances for Show (a -> b)
arising from a use of `property'
Matching instances:
instance Show (a -> b) -- Defined in Text.Show.Functions
instance Show base:System.Event.Manager.IOCallback
-- Defined in base:System.Event.Manager
(The choice depends on the instantiation of `a, b'
To pick the first instance above, use -XIncoherentInstances
when compiling the other instance declarations)
In the second argument of `($)', namely
`property (undefined :: (a -> b) -> Bool)'
In the expression: const $ property (undefined :: (a -> b) -> Bool)
In an equation for `f':
f = const $ property (undefined :: (a -> b) -> Bool)
$ ghc --make -c -O T1 T2
[2 of 2] Compiling T1 ( T1.hs, T1.o )
$ ghc --make -c -O T1 T2
$ ls
T1.hi T1.hs T1.o T2.hi T2.hs T2.o
</pre><p>
I see this consistent behaviour in versions 7.0.{1,2,3,4} but not with 6.12.1
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5316#changelog