We should add a test. I imagine with a trivial example it should be easy to verify that allowInterrupt (the real bug) works properly now, no?

Regarding bikeshedding on the exports: we already do export other mask-related facilities from Control.Exception, so adding another 'safe' export (vs unsafeMask) seems reasonable to me. Some other people should weigh in.

I'm adding @hvr and @ekmett to see if they have any input, re: point 2.

Actually I'm not sure about interruptible, because it sidesteps the scoping we get with mask. The restore function passed to mask can only unmask exceptions if the enclosing context was unmasked, whereas interruptible as defined here unconditionally unmasks interrupts. Therefore it is unsafe, like unsafeUnmask but less so (it only punches a hole in mask, not uninterruptibleMask). So if we have it, it should have "unsafe" in its name.

I don't insist on the name, of course. However, it seems to me that "punching a hole through mask" is precisely what "interruptible" means. When we say that takeMVar is interruptible, that is what we mean, I think?

(I came across the problem in the first place precisely because I wanted to be able to define my own interruptible resource allocation functions; see http://www.well-typed.com/blog/97/ ).

Then again, I suppose it can be argued even takeMVar is dangerous and should really be called unsafeTakeMVar for the same reason :)