Proposal: Add forkOSWithUnmask to Control.Concurrent

Joey Adams joeyadams3.14159 at
Sat Jun 22 16:50:40 CEST 2013

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
[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: .  The title "Add
forkOSUnmasked" is a mistake (should be "Add forkOSWithUnmask"), but the
patch should be right.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list