Monitor groups of threads with non-hierarchical lifetimes.
The supervisors package provides a useful abstraction for managing the groups of Haskell threads, which may not have a strictly hierarchical structure to their lifetimes.
Concretely, the library provides a Supervisor construct, which can be used to safely spawn threads while guaranteeing that:
When the supervisor is killed, all of the threads it supervises will be killed.
Child threads can terminate in any order, and memory usage will always be proportional to the number of *live* supervised threads.
One way to think of it is that supervisors is to async as resourcet is to bracket.
Note that this package is EXPERIMENTAL; it needs more careful testing before I can earnestly recommend relying on it.
See the README and module documentation for more information.
Haskell Supervisors
The supervisors package provides a useful abstraction for managing the groups of Haskell threads, which may not have a strictly hierarchical structure to their lifetimes.
One way to think of it is that supervisors is to async as resourcet is to bracket.
Most of the time you can manage these things in a hierarchical manner: for bracket, acquire a resource, do stuff with it, and release it. For async, spawn some tasks, wait for some or all of them, maybe kill the remaining ones, and return. The memory used by all of these threads is not reclaimed until the entire subtree finishes.
But sometimes, your concurrency patterns don't fit neatly into a tree; that is what this package is for.
This package was originally written for use in the rpc layer of the capnp package, where the various threads handling rpc calls can have essentially arbitrary lifetimes, but we often want to make sure they are all shut down when a connection is closed.
Concretely, the library provides a Supervisor construct, which can be used to safely spawn threads while guaranteeing that:
- When the supervisor is killed, all of the threads it supervises will be killed.
- Child threads can terminate in any order, and memory usage will always be proportional to the number of live supervised threads.