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.
On Posix, the timer signal is implemented by calling timer_create() to generate regular SIGVTALRM signals (this was changed from SIGALRM in #850 (closed)).
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.
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.
RTS Alarm Signals and Foreign Libraries
When using foreign libraries through the Haskell FFI, it is important
to ensure that the foreign code is capable of dealing with system call
interrupts due to alarm signals GHC is generating.
For example, in this strace output
a select call is interrupted, but the foreign C code interprets the
interrupt as an application error and closes a critical file