On 2 July 2016 at 17:25, Edward Z. Yang <ezyang@mit.edu> wrote:

Excerpts from Simon Marlow's message of 2016-07-02 05:58:14 -0400:
> > Claim 1: Here is some code which reimplements 'unblock':
> >
> > import Control.Exception
> > import Control.Concurrent
> > import Control.Concurrent.MVar
> >
> > unblock :: IO a -> IO a
> > unblock io = do
> > m <- newEmptyMVar
> > _ <- forkIO (io >>= putMVar m)
> > takeMVar m
> >
> >
> This isn't really an implementation of unblock, because it doesn't enable
> fully-asynchronous exceptions inside io. If a stack overflow occurs, it
> won't be thrown, for example. Also, io will not be interrupted by an
> asynchronous exception thrown to the current thread.

Oh, that's true. I suppose you could work around this by passing
on an asynchronous exception to a child thread that is unmasked
using forkIOWithUnmask, although maybe you would consider that
cheating?

Yes, you can use forkIOWithUnmask as a way to break out of mask. Perhaps for that reason it should have "unsafe" in the name, but I think it's hard to use it by accident.

I actually do agree with you that the "modularity" provided by mask isn't really useful. But my reasoning is a bit different.

The caller of mask is saying "I want asynchronous exceptions to only occur at known places.". Those known places are interruptible operations, and library code (because we can't know whether library code performs an interruptible operation or not). From the point of view of the caller of mask, they cannot tell the difference between library code that invokes an interruptible operation, and library code that calls "unblock". So it would be perfectly fine to provide an "unblock" that re-enables fully asynchronous exceptions.

(indeed I think this was kind of what I had in mind with the original block/unblock, but I didn't articulate the argument clearly enough when everyone was asking for "mask")

However, things are a bit different with uninterruptibleMask. Here the caller is saying "I don't expect to see *any* asynchronous exceptions, either in my code or from library code". So clearly an unblock cannot undo an uninterruptibleMask.

Having said all this, I don't think the current API is necessarily bad, it just provides more guarantees than we really need, and perhaps it's a bit less efficient than it could be, due to the need to pass the IO action to mask. But we would still need to do this for uninterruptibleMask, and having the API of uninterruptibleMask be the same as mask is good.

> We already have a way to allow asynchronous exceptions to be thrown within
> a mask, it's called allowInterrupt:
> http://hackage.haskell.org/package/base-4.9.0.0/docs/Control-Exception.html#v:allowInterrupt

Well, it's different, right? allowInterrupt allows asynchronous exceptions to
be thrown at a specific point of execution; unblock allows asynchronous
exceptions to be thrown at any point while the inner IO action is
executing. I don't see why you would allow the former without the
latter.

Ok, so the point I was trying to make was that the idea of blocking to allow asynchronous exceptions to be thrown inside a mask is fully sanctioned, and we made an API for it. But you're quite right that it's not exactly the same as unblock.

> > You could very well argue that interruptible actions are a design flaw.
> >
>
> I disagree - it's impossible to define withMVar without interruptible mask.

What about this version of withMVar using uninterruptible? (Assume
no other producers.)

withMVarUninterruptible :: MVar a -> (a -> IO b) -> IO b
withMVarUninterruptible m io =
uninterruptibleMask $ \restore -> do
a <- restore (takeMVar m)
b <- restore (io a) `onException` putMVar m a
putMVar m a
return b

I don't think it is quite right, as there is race between when
takeMVar unblocks, and when the uninterruptible mask is restored.
But perhaps the primary utility of interruptible masks is to
let you eliminate this race.

Exactly! This race condition is the reason for interruptible operations.

[snip]

Edward

Cheers

Simon