Interruptible exception wormholes kill modularity

[Edward Z. Yang]

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.

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.

> 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?

Cheers,
Edward