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@. 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 --------------------