The documentation for forkIO
says
GHC note: the new thread inherits the masked state of the parent (see mask).
The newly created thread has an exception handler that discards the exceptions
BlockedIndefinitelyOnMVar, BlockedIndefinitelyOnSTM, and ThreadKilled, and passes
all other exceptions to the uncaught exception handler.
Why does the child exception handler discard ThreadKilled
? Is there some connection between the two threads after they're created?
What exactly happens when the parent thread dies? Does the child get any exception raised? Or is there any way at all to see from the child's perspective that the parent died? Is there anything else that happens except that the parent thread just stops running?
The reason why I'm asking this is that in many cases I'm forced to create a thread in a context where I can't access the parent's scope. Just imagine you're somewhere deep in a library and need to call forkIO
, and have that thread die when the parent dies. Is it necessary to restructure the program and propagate the child's ThreadId
up to the parent and explicitly kill it? Or is there any other workaround for this?
Nothing. That's actually also true for POSIX threads. Threads don't share the parent-child relationship you might know from
fork
in C or similar languages. There is, however, one main thread, and its termination will usually lead to the termination of the whole program:No. No. And no. For the same reason as with usual OS threads. You can try this pretty easily:
The "parent" will say goodbye, and the "children" will print a second later. Remember, there is no actual parent in thread programming. There are only siblings. One of them is a little bit special, yes, but that is just how it's been specified.
At least a little bit, since
forkIO
doesn't provide this. Also, if there was aforkIOKillAutomatically
, what type should it have? And why?Well, you could provide the rest of your
parent
as another action, and therefore use a helper:The above example would then become
In this case the only output will be
See also:
forkRunDie
withfinally
).https://hackage.haskell.org/package/base-4.7.0.0/docs/Control-Concurrent.html#g:12
This is an answer inspired by Zeta's. It uses a free monad transformer to avoid explicit nesting of computations, and the
withAsync
function from theasync
package instead offorkRunDie
.