Go to the first, previous, next, last section, table of contents.

Potential problems with Concurrent Haskell

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, 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. 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.


Go to the first, previous, next, last section, table of contents.