Final bikeshedding call: Fixing Control.Exception.bracket

[John Lato]

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

>
> On Tue, Nov 11, 2014 at 10:09 AM, Merijn Verstraaten <
> merijn at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141113/8c392d6e/attachment-0001.html>