|Maintainer||Bas van Dijk <email@example.com> , Roel van Dijk <firstname.lastname@example.org>|
Standard threads extended with the ability to wait for their termination.
Inspired by: http://hackage.haskell.org/package/threadmanager
This module re-implements several functions from
ambiguities by importing one or both qualified. We suggest importing this
import qualified Control.Concurrent.Thread as Thread ( ... )
- data ThreadId
- threadId :: ThreadId -> ThreadId
- forkIO :: IO () -> IO ThreadId
- forkOS :: IO () -> IO ThreadId
- wait :: ThreadId -> IO (Maybe SomeException)
- waitTimeout :: ThreadId -> Integer -> IO (Maybe (Maybe SomeException))
- isRunning :: ThreadId -> IO Bool
- killThread :: ThreadId -> IO ()
- killThreadTimeout :: ThreadId -> Integer -> IO Bool
- throwTo :: Exception e => ThreadId -> e -> IO ()
ThreadId is an abstract type representing a handle to a thread.
is an instance of
Show, where the
Ord instance implements an
arbitrary total ordering over
Show instance lets you convert
ThreadId to string form; showing a
ThreadId value is
occasionally useful when debugging or diagnosing the behaviour of a concurrent
Note: This is a wrapper around
The new thread will be a lightweight thread; if you want to use a foreign
library that uses thread-local storage, use
GHC note: the new thread inherits the blocked state of the parent (see
The newly created thread has an exception handler that discards the exceptions
ThreadKilled, and passes all
other exceptions to the uncaught exception handler (see
forkOS instead of
forkIO makes no difference at all to the scheduling
behaviour of the Haskell runtime system. It is a common misconception that you
need to use
forkOS instead of
forkIO to avoid blocking all the Haskell
threads when making a foreign call; this isn't the case. To allow foreign calls
to be made without blocking all the Haskell threads (with GHC), it is only
necessary to use the
-threaded option when linking your program, and to make
sure the foreign import is not marked
True if the given thread is currently running.
Notice that this observation is only a snapshot of thread's state. By the time a program reacts on its result it may already be out of date.
killThread terminates the given thread (GHC only). Any work already done by
the thread isn't lost: the computation is suspended until required by another
thread. The memory used by the thread will be garbage collected if it isn't
referenced from anywhere. The
killThread function is defined in terms of
This function blocks until the target thread is terminated. It is a no-op if the target thread has already completed.
killThread but with a timeout. Returns
True if the target thread was
terminated without the given amount of time,
The timeout is specified in microseconds.
Note that even when a timeout occurs, the target thread can still terminate at a later time as a direct result of calling this function.
throwTo raises an arbitrary exception in the target thread (GHC only).
throwTo does not return until the exception has been raised in the target
thread. The calling thread can thus be certain that the target thread has
received the exception. This is a useful property to know when dealing with race
conditions: eg. if there are two threads that can kill each other, it is
guaranteed that only one of the threads will get to kill the other.
If the target thread is currently making a foreign call, then the exception will
not be raised (and hence
throwTo will not return) until the call has
completed. This is the case regardless of whether the call is inside a
Important note: the behaviour of
throwTo differs from that described in the
paper "Asynchronous exceptions in Haskell"
(http://research.microsoft.com/~simonpj/Papers/asynch-exns.htm). In the paper,
throwTo is non-blocking; but the library implementation adopts a more
synchronous design in which
throwTo does not return until the exception is
received by the target thread. The trade-off is discussed in Section 9 of the
paper. Like any blocking operation,
throwTo is therefore interruptible (see
Section 5.3 of the paper).
There is currently no guarantee that the exception delivered by
be delivered at the first possible opportunity. In particular, a thread may
unblock and then re-
block exceptions without receiving a pending
throwTo. This is arguably undesirable behaviour.