thread-hierarchy: Simple Haskel thread management in hierarchical manner

[ concurrency, library, mit ] [ Propose Tags ]

This package provides parent-child association and guaranteed clean-up of children over plain Haskell thread. You can terminate all child threads and grand child threads by just killing their parent thread. asynchronous exception.

[Skip to Readme]


Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees


  • No Candidates
Versions [RSS],,,,,,,
Change log
Dependencies base (>=4.7 && <5), containers, lifted-base, monad-control, transformers-base [details]
License MIT
Copyright Copyright: (c) 2017 Naoto Shimazaki
Author Naoto Shimazaki
Category Concurrency
Home page
Source repo head: git clone
Uploaded by nshimaza at 2017-10-14T04:43:00Z
Distributions LTSHaskell:, NixOS:, Stackage:
Reverse Dependencies 1 direct, 0 indirect [details]
Downloads 4972 total (26 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs available [build log]
Last success reported on 2017-10-14 [all 1 reports]

Readme for thread-hierarchy-

[back to package description]


License: MIT Build Status Hackage Stackage Nightly Stackage LTS

Managing Haskell threads in hierarchical manner.


This package provides parent-child association and guaranteed clean-up of children over plain Haskell thread. You can terminate all child threads and grand child threads by just killing their parent thread.


Unlike Unix process, plain Haskell thread, created by forkIO, has no parent-child relation each other. This means termination of parent thread doesn't result its children also terminated. This is good design as it is low level API because it gives programmer greatest flexibility. However, it also means managing entire lifecycle of thread is totally a responsibility of programmer.

Here one thing you need to be aware. Garbage collection doesn't work on living thread. When you lost reference to an object, garbage collector frees up the object for you. However, even though you lost the thread ID of your child thread, Haskel runtime doesn't consider the thread is orphaned. The child thread continue running.

This is prone to create thread leakage. You can accidentally lose thread ID of child thread by crash of parent thread. Now you no longer have way to kill orphaned child thread. This is thread leakage.

The low level forkIO API requires you keep track and manage entire thread lifecycle including accidental case like the above. Hand crafting it might be painful.

This package is intended to provide simple replacement API over plain forkIO in case of when all you need to do on parent termination is just terminating all its children.

If you need to keep your child running after parent terminated, this API is not for you.


Almost all you need to know is one data type and one function: ThreadMap and newChild.

Threads created by newChild guarantee automatic cleanup on its exit regardless normal exit or cancellation by asynchronous exception.

In order to that works properly, user must ensure following rules.

  • User provided thread handler must accept ThreadMap as its first argument.
  • When the user provided handler creates its child thread, it must use newChild with given ThreadMap.
  • For 1st thread you create by newChild, give it a ThreadMap created by newThreadMap.

ThreadMap is house-keeping object for your thread. It is a mutable map keeping track living child threads of your thread. When your thread handler started, you receives an empty ThreadMap via 1st argument of your handler. When you create a child thread of your thread, newChild automatically update (mutate) your ThreadMap by adding newly created child thread. When your child thread terminated, it is automatically removed from your ThreadMap.

Same manner is applied to child thread and grandchild thread as long as you follow the rule the above.

How it works

When newChild creates a new thread, it installs two cleanup tasks for you.

  • Killing all thread contained in ThreadMap of the new thread. It kills all children of the new thread.
  • Removing the new thread itself from parent's ThreadMap.

The cleanup tasks are called when the new thread exit normally or terminated by asynchronous exception. By this mechanism, termination of top level thread is propagated down to all its children, children of children, and so on.


When you create the first thread managed by this module, create a new empty ThreadMap then call newChild with it. The newCall automatically install cleanup routine to the handler you provided.

createRootThread :: IO ThreadId
createRootThread = do
    rootThreadMap <- newThreadMap
    threadID <- newChild rootThreadMap rootThreadHandler
    return threadID

When a thread managed by this module creates its child thread, call newChild with TreadMap received via handlers argument.

rootThreadHandler :: ThreadMap -> IO ()
rootThreadHandler myChildrenThreadMap = do
    void $ newChild myChildrenThreadMap $ \grandChildrenThreadMap -> do
        return ()

You can install your own cleanup routine using finally or both resource acquisition and cleanup routine using bracket.

    -- Forking a new child with your own cleanup
    void $ newChild childrenOfCurrentThread $ \childrenOfHandler ->
        yourThreadHandler `finally` yourCleanupRoutine

    -- Forking a new child with resource acquisition and cleanup
    void $ newChild childrenOfCurrentThread $ \childrenOfHandler ->
        bracket yourResourceAcquiringRoutine yourCleanupRoutine yourThreadHandler

You can also find a use case from tcp-server package.


Currently, unlike async function, this module is not designed to back any return value from child thread to parent thread. This module focuses on guaranteed cleanup on thread termination.