#1419: "GHC as a library" stalls when nobody is consuming it's output
-----------------------+----------------------------------------------------
Reporter: simonmar | Owner:
Type: bug | Status: new
Priority: high | Milestone: 6.8
Component: GHC API | Version: 6.6.1
Severity: normal | Keywords:
Difficulty: Unknown | Os: Unknown
Testcase: | Architecture: Unknown
-----------------------+----------------------------------------------------
Reported by Mads Lindstrøm <[EMAIL PROTECTED]> on glasgow-haskell-
users:
While trying to implement a GUI for GHCi, I have run into an annoying
concurrency problems. I think "GHC as a library" is at fault, as it
stalls (maybe some deadlock) when nobody is consuming it's output.
This message is a literate Haskell program, which illustrates the
problem.
This test-program starts a thread which prints an 'A' on stderr every
second. Then it wait three seconds (meanwhile the 'A's are printing),
and runs, via "GHC as a library", the following Haskell code "[1..]".
If I start the program as:
{{{
./IsGhcBlocking >/dev/null
}}}
everything works fine and the 'A' keeps coming out on stderr.
However, if I do:
{{{
./IsGhcBlocking | sleep 10
}}}
I only see three 'A's. I believe that is because the sleep-command, do
not consume any input.
The program was tested on Debian Etch running GHC 6.6.
{{{
> module Main where
>
Compile with: ghc -threaded -package ghc-6.6 --make IsGhcBlocking.lhs
> import qualified GHC as GHC
> import qualified Outputable as GHC
> import qualified Packages as GHC
> import qualified DynFlags as GHC
> import qualified ErrUtils as GHC
>
> import System.IO
> import Control.Concurrent
> -- the path of our GHC 6.6 installation
> path :: FilePath
> -- path = "c:\\ghc-6.6"
> path = "/usr/lib/ghc-6.6/"
>
> main :: IO()
> main = do let printAs = do threadDelay (10^6)
> hPutStrLn stderr "A"
> printAs
> forkOS printAs -- forkIO gives the same result
> threadDelay (10^6 * 3)
> session <- initializeSession
> GHC.runStmt session "[1..]"
> return ()
>
> initializeSession =
> do session <- GHC.newSession GHC.Interactive (Just path)
>
> -- initialize the default packages
> dflags0 <- GHC.getSessionDynFlags session
> let myLogAction _ locSpec style errMsg = hPutStrLn stderr showMsg
where
> showMsg = GHC.showSDoc $ GHC.withPprStyle style $
GHC.mkLocMessage locSpec errMsg
> dflags1 = dflags0 { GHC.log_action = myLogAction }
> (dflags2, packageIds) <- GHC.initPackages dflags1
> GHC.setSessionDynFlags session
dflags2{GHC.hscTarget=GHC.HscInterpreted}
> GHC.setContext session [] []
> return session
}}}
The stalling becomes a problem, when one wants to interrupt "GHC as a
library"'s runStmt function. One could interrupt "GHC as a library" with
Panic.interruptTargetThread (see
http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/12289).
However,
as "GHC as a library" locks up (stalls, deadlocks) there is no way of
executing Panic.interruptTargetThread.
Some people may suggest that I should always consume the output from
"GHC as a library". But that is easier said than done. Many GUI
libraries (including !WxHaskell, which I am using) only allows for one
active thread at a time (see
http://wxhaskell.sourceforge.net/faq.html). Thus my GUI cannot
simultaneously tell "GHC as a library" to interrupt it's execution and
read it's output.
For thus wondering how I can run both a GUI and "GHC as a library", if
!WxHaskell is not happy about threading, the answer is that I run the
GUI and "GHC as a library" in separate processes.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1419>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
