Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,929
    • Issues 4,929
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 461
    • Merge requests 461
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #4162
Closed
Open
Created Jun 30, 2010 by Daniel Gorín@jcpetruzzaReporter

GHC API messes up signal handlers

A side-effect of using the runGhc function is that some signal handlers are modified and not restored afterwards (see function initGhcMonad). In particular, the handler for SIGINT installed by ghc throws an exception to a thread stored in a global variable, which initially corresponds to the thread from which runGhc was run.

This is a particularly problematic for programs that wish to run ghc "in the background" on its own thread. For example, consider this code:

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"

One can interrupt this program with Ctrl-C during the first five seconds of execution only.

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:

runGhc action

into something like this:

runGhc $ (liftIO restoreProgramHandlers >> action)

but I don't know if this is safe (i.e., what happens if ghc is run without its own handlers installed).

Trac metadata
Trac field Value
Version 6.12.3
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component GHC API
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking