Proposal: Use uninterruptibleMask for cleanup actions in Control.Exception

[Herbert Valerio Riedel]

Hello, 

I'm forwarding this on behalf of Edsko:

-------------------- Start of forwarded message --------------------
[...]

Hi Herbert,

> ...and I'd like to point your attention to yet another related proposal
> that came in yesterday:
> 
>  Subject: Proposal: Use uninterruptibleMask for cleanup actions in
>           Control.Exception
> 
>  http://thread.gmane.org/gmane.comp.lang.haskell.libraries/22775

Hmmm, I thought I was subscribed to libraries at . It seems I wasn’t. I
subscribed earlier today but haven’t got the confirmation email yetI
(?). Perhaps you can forward my reply for now?

Anyhow, I’m not convinced about this proposal. uninterruptibleMask is
rather crude. It would be one thing to block, say, timeout signals
during resource cleanup (perhaps), but uninterruptibleMask blocks _all_
asynchronous exceptions, including stack overflow and heap overflow. I
don’t think that the _default_ behaviour of bracket should be to disable
those.

Note also that in the

bracket takeMVar putMVar

example, the putMVar is _NOT_ interruptible. By definition, putMVar is
interruptible _only_ if the resource is not available. Since the
takeMVar succeeded, the MVar must be empty at the time of the putMVar
and hence it cannot be interrupted. (This is assuming of course that
there are no putMVars in the body of the bracket, but if you’re doing
that, you have bigger problems..). Incidentally, if that behavior of
putMVar is not in fact the case, then that is a bug in putMVar, not in
bracket.

The hClose example ironically _is_ an example, though it doesn’t look
like one — Merijn is right, it uses an MVar under the hood and in fact
it does a withMVar, which is interruptible, of course — in case somebody
else happens to have the file handle at that time. But again, I’m not
sure what the right answer is. I sort of feel that these file operations
should _not_ be interruptible. The fact that they use MVars under the
hood makes them so, but perhaps that could be considered a bug (and they
should do some uninterruptibleMasking of their own) — certainly, as far
as I know, it’s nowhere actually _documented_ that these operations are
interruptible and most people don’t think of them as such.

I’m not sure to be honest. I would like Simon Marlow’s opinion here. But
my feeling right now is that I’d vote against this, but to try and make
sure that the operations we use in cleanup handlers are, in fact, not
interruptible.

-E
-------------------- End of forwarded message --------------------