Interruptible exception wormholes kill modularity

[Simon Marlow]

On 2 July 2016 at 17:25, Edward Z. Yang <ezyang at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160704/cbbeb667/attachment.html>