The supervised combinator lets one fork freely and have the runtime automatically clean up fibers when the inner block exits. I think we could potentially extend this API to have more control over things like unhandled exceptions.
Implementation-wise, the supervision context is essentially a MonadReader environment. When we fork anything, we pull out the supervision context and use that to track fibers. I think we could potentially reify this environment, giving authors control over which supervisors run which fibers, and also what happens when they exit abnormally.
As a baseline, I could imagine an API like:
data Supervisor eff
makeSupervisor :: forall eff. Aff eff (Supervisor eff)
-- We need a special global supervisor.
-- Equivalent to `ask`.
getCurrentSupervisor :: forall eff. Aff eff (Supervisor eff)
-- Equivalent to `local`
runWithSupervisor :: forall eff a. Supervisor eff -> Aff eff a -> Aff eff a
-- Tracks Fiber using provided supervisor
forkWithSupervisor :: forall eff a. Supervisor eff -> Aff eff a -> Aff eff (Fiber eff a)
-- Kills all pending Fibers
killAll :: forall eff. Error -> Supervisor eff -> Aff eff Unit
Which we could use to implement existing functionality. supervised would then be something like:
supervised aff = do
sup <- makeSupervisor
finally (killAll sup) $ runWithSupervisor sup aff
And fork would be something like:
fork aff = do
sup <- getCurrentSupervisor
forkWithSupervisor sup aff
Some possible ways to extend the API:
- Supervisor delegation: create a context extended from a parent context.
- Respond to unhandled exceptions.
- A way to associate some tag/state/process id with a Fiber.
The
supervisedcombinator lets one fork freely and have the runtime automatically clean up fibers when the inner block exits. I think we could potentially extend this API to have more control over things like unhandled exceptions.Implementation-wise, the supervision context is essentially a
MonadReaderenvironment. When we fork anything, we pull out the supervision context and use that to track fibers. I think we could potentially reify this environment, giving authors control over which supervisors run which fibers, and also what happens when they exit abnormally.As a baseline, I could imagine an API like:
Which we could use to implement existing functionality.
supervisedwould then be something like:And
forkwould be something like:Some possible ways to extend the API: