|Version 2 (modified by simonmar, 8 years ago) (diff)|
The GHC Commentary: Signals
This section describes how the RTS interacts with the OS signal facilities. Throughout we use the term "signal" to refer to both POSIX-style signals and Windows ConsoleEvents.
Signal handling differs between the threaded version of the runtime and the non-threaded version (see Commentary/Rts/Config). Here we discuss only the threaded version, since we expect that to become the standard version in due course.
- POSIX signal handling:
- Windows console events:
Signal handling in the RTS
The RTS is interested in two signals: a timer signal, and an interrupt signal.
The timer signal
The timer signal is used for several things:
- To cause the scheduler to context switch
- Sampling for time profiling
- To detect deadlock (see Commentary/Rts/Scheduler)
- The timer interrupt handler, and starting/stopping the timer:
- Platform-independent ticker interface, used by the timer:
- Posix implementation of ticker:
- Windows implementation of ticker:
On Posix, the timer signal is implemented by calling setitimer() to generate regular SIGALRM signals. This isn't ideal, since we'd like to allow the application t so use SIGALRM if it needs to. Ideally we should use something better (see #850).
On Windows, we spawn a new thread that repeatedly sleeps for the timer interval and then executes the timer interrupt handler.
The interrupt signal
The interrupt signal is SIGINT on POSIX systems or CTRL_C_EVENT/CTRL_BREAK_EVENTon Windows, and is normally sent to the process when the user hits Control-C. By default, interrupts are handled by the runtime. They can be caught and handled by Haskell code instead, using System.Posix.Signals on POSIX systems or GHC.ConsoleHandler on Windows systems. For example, GHCi? hooks the interrupt signal so that it can abort the current interpreted computation and return to the prompt, rather than terminating the whole GHCi process.
When the interrupt signal is received, the default behaviour of the runtime is to attempt to shut down the Haskell program gracefully. It does this by calling interruptStgRts() in rts/Schedule.c (see Commentary/Rts/Scheduler). If a second interrupt signal is received, then we terminate the process immediately; this is just in case the normal shutdown procedure failed or hung for some reason, the user is always able to stop the process with two control-C keystrokes.
Signal handling in Haskell code
- POSIX: rts/posix/Signals.h, rts/posix/Signals.c
- Windows: rts/win32/ConsoleHandler.h, rts/win32/ConsoleHandler.c
A Haskell program can ask to install signal handlers, via the System.Posix.Signals API, or GHC.ConsoleHandler on Windows. When a signal arrives that has a Haskell handler, it is the job of the runtime to create a new Haskell thread to run the signal handler and place the new thread on the run queue of a suitable Capability.
When the runtime is idle, the OS threads will all be waiting inside yieldCapability(), waiting for some work to arrive. We want a signal to be able to create a new Haskell thread and wake up one of these OS threads to run it, but unfortunately the range of operations that can be performed inside a POSIX signal handler is extremely limited, and doesn't include any inter-thread synchronisation (because the signal handler might be running on the same stack as the OS thread it is communicating with).
The solution we use, on both Windows and POSIX systems, is to pass all signals that arrive to the IO Manager thread. On POSIX this works by sending the signal number down a pipe, on Windows it works by storing the signal number in a buffer and signaling the IO Manager's Event object to wake it up. The IO Manager thread then wakes up and creates a new thread for the signal handler, before going back to sleep again.