Chris Kuklewicz wrote:
forkInheritIO :: IO () -> IO ThreadId -- inherits parent's block or unblock status
forkBlockedIO :: IO () -> IO ThreadId -- starts the action in "block" mode. Must manually "unblock"
Either of these is certainly possible, and I agree that forkBlockedIO is more general than my forkCatchIO. One tantalising possibility is that we could make forkIO have the forkInheritIO behaviourthe default without breaking much code
where forkBlockedIO could be written as "block . forkInheritIO" and forkIO is "unblock . forkInheritIO" but there is no way to write forkInheritIO since I can't query the current block|unblock status dynamically. I have no use for forkInheritIO but perhaps some library code would want to play nice with the calling application.
If either of those two functions existed then one could write "forkCatchIO" (which is unblocked) using it:
forkCatchBlockedIO hander io = forkBlockedIO (handle handler io) forkCatchIO handler = (forkChatchBlockedIO handler) . unblock
I propose adding at least "forkInheritIO" or "forkBlockedIO" as a primitive and perhaps "forkCatchIO" or "forkCatchBlockedIO" as a primitive if there is a performance gain.
Cheers, Chris