On Wed Nov 12 2014 at 8:02:02 AM Gregory Collins <greg@gregorycollins.net> wrote:

On Tue, Nov 11, 2014 at 10:09 AM, Merijn Verstraaten <merijn@inconsistent.nl> wrote:
Potential solution #1:
Leave bracket as-is, add bracketUninterruptible with an uninterruptible cleanup handler.

Potential solution #2:
Change bracket to use uninterruptible cleanup handler, add bracketInterruptible for interruptible cleanups.

I'm strongly -1 on #2, at least until its proponents demonstrate that they have done some due diligence to demonstrate that common libraries and frameworks still work as expected after the change. For example: is code that expects to be able to e.g. block on a takeMVar inside the cleanup block still going to be killable with killThread?

Changing the semantics of such a commonly-used function in this way is almost guaranteed to cause unforeseen issues. I think the burden of proof should be on proponents to demonstrate that this change is likely to be safe, rather than asking those opposed to dig around to find examples that break.

I agree that this is highly likely to cause unforeseen issues. However, in this case I think the pain of fixing those unknown issues is likely to be much less work in the long run than difficulties caused by the status quo. I'd rather have deadlocks (at least this kind of deadlock) than resource leaks, so I do think the proposal is better than the status quo even with unknown costs. I'm wondering how your cost benefit analysis differs from mine here. Do you think the current resource leaking issue is not particularly significant, or do you tend to think it's an issue that should be fixed, but you're weighting the unknown costs much more than I am?