-The main thread in a Concurrent Haskell program is given its own
-private stack space, but all other threads are given stack space from
-the heap. Stack space for the main thread can be
-adjusted as usual with the @-K@ RTS
-option,<nidx>-K RTS option (concurrent, parallel)</nidx> but if this
-private stack space is exhausted, the main thread will switch to stack
-segments in the heap, just like any other thread. Thus, problems
-which would normally result in stack overflow in ``sequential Haskell''
-can be expected to result in heap overflow when using threads.
-
-The concurrent runtime system uses black holes as synchronisation
-points for subexpressions which are shared among multiple threads. In
-``sequential Haskell'', a black hole indicates a cyclic data
-dependency, which is a fatal error. However, in concurrent execution, a
-black hole may simply indicate that the desired expression is being
-evaluated by another thread. Therefore, when a thread encounters a
-black hole, it simply blocks and waits for the black hole to be
-updated. Cyclic data dependencies will result in deadlock, and the
-program will fail to terminate.
-
-Because the concurrent runtime system uses black holes as
-synchronisation points, it is not possible to disable black-holing
-with the @-N@ RTS option.<nidx>-N RTS option</nidx> Therefore, the use
-of signal handlers (including timeouts) with the concurrent runtime
-system can lead to problems if a thread attempts to enter a black hole
-that was created by an abandoned computation. The use of signal
-handlers in conjunction with threads is strongly discouraged.
-
+The previous implementation of Concurrent Haskell in GHC had problems
+with using signals handlers in concurrent programs. The current
+system, however, provides thread-safe signal handling (see Section
+<ref name="Signal Handling" id="signals">).