[Haskell-cafe] Interruptible exception wormholes kill modularity

[Yuras Shumovich]

On Sat, 2016-07-02 at 12:29 -0400, Edward Z. Yang wrote:
> Excerpts from Yuras Shumovich's message of 2016-07-02 09:06:59 -0400:
> > On Sat, 2016-07-02 at 00:49 -0400, Edward Z. Yang wrote:
> > > 
> > > P.P.S. I have some speculations about using uninterruptibleMask
> > > more
> > > frequently: it seems to me that there ought to be a variant of
> > > uninterruptibleMask that immediately raises an exception if
> > > the "uninterruptible" action blocks.  This would probably of
> > > great assistance of noticing and eliminating blocking in
> > > uninterruptible code.
> > 
> > 
> > Could you please elaborate where it is useful. Any particular
> > example?
> 
> You would use it in any situation you use an uninterruptibleMask.
> The point is that uninterruptible code is not supposed to take
> too long (the program is unresponsive in the meantime), so it's
> fairly bad news if inside uninterruptible code you block.  The
> block = exception variant would help you find out when this occurred.

Hmm, ununterruptibleMask is used when the code can block, but you don't
want it to throw (async) exception. waitQSem is an example:
https://hackage.haskell.org/package/base-4.9.0.0/docs/src/Control.Concurrent.QSem.html#waitQSem

Basically, there are cases where code can block, yet you don't want it
to be interrupted. Why to you need uninterruptibleMask when the code
can't block anyway? It is a no-op in that case.

> 
> Arguably, it would be more Haskelly if there was a static type
> discipline for distinguishing blocking and non-blocking IO
> operations.
> But some operations are only known to be (non-)blocking at runtime,
> e.g., takeMVar/putMVar, so a dynamic discipline is necessary.

That is correct. In theory it would be useful to encode on type level
whether IO operations can block, or can be iterrupted by async
exception, or can fail with sync exception. Unfortunately it depends on
runtime, so in practice it is less useful.

> 
> > I'm interested because few years ago I proposed similar function,
> > but
> > in a bit different context. I needed it to make interruptible
> > cleanup
> > actions safe to use.
> 
> Could you elaborate more / post a link?

Sorry, I thought I added the link. I'm talking about this:
http://blog.haskell-exists.com/yuras/posts/handling-async-exceptions-in-haskell-pushing-bracket-to-the-limits.html#example-6-pushing-to-the-limits

The idea is to disable external async exceptions, but interrupt any
interruptable operation on the way. The article describes the reason I
need it.

Thanks,
Yuras.