We have forkIOWithUnmask[1] and forkOnWithUnmask[2], but we don't have forkOSWithUnmask. This proposal would add it: -- | Like 'forkIOWithUnmask', but the child thread is a bound thread, -- as with 'forkOS'. forkOSWithUnmask :: ((forall a . IO a -> IO a) -> IO ()) -> IO ThreadId forkOSWithUnmask io = forkOS (io unsafeUnmask) For GHC < 7.8, forkOSWithUnmask can be achieved using forkOS and blockhttp://hackage.haskell.org/packages/archive/base/4.6.0.1/doc/html/Control-Ex... [3], but block is removed in GHC 7.8. unsafeUnmask can still be imported from GHC.IO, however. Impact: virtually no compatibility break (just adds a new definition), but we will probably want to update the async package[4] at some point, adding asyncBoundWithUnmask and withAsyncBoundWithUnmask. Such an addition would not require base >= 4.7 in async, as we could use the `block` workaround described above. The biggest objection I can imagine would be that we now have six basic ways to fork a thread: forkIO, forkOn, forkOS, and their fork*WithUnmask variants. Libraries like async end up having to replicate all these. Perhaps in the future, we should consolidate forkIO, forkOn, and forkOS: data ThreadMode = ForkIO | ForkOn Int | ForkBound forkMode :: ThreadMode -> IO () -> IO () forkModeWithUnmask :: ThreadMode -> ((forall a. IO a -> IO a) -> IO ()) -> IO ThreadId But for now, adding forkOSWithUnmask mirrors forkIOWithUnmask and forkOnWithUnmask, which are already in place. Ticket: http://hackage.haskell.org/trac/ghc/ticket/8010 . The title "Add forkOSUnmasked" is a mistake (should be "Add forkOSWithUnmask"), but the patch should be right. [1]: http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Con... [2]: http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Con... [3]: http://hackage.haskell.org/packages/archive/base/4.6.0.1/doc/html/Control-Ex... [4]: http://hackage.haskell.org/packages/archive/async/latest/doc/html/Control-Co...