Final bikeshedding call: Fixing Control.Exception.bracket
Michael Snoyman
michael at snoyman.com
Thu Nov 13 06:06:24 UTC 2014
On Wed Nov 12 2014 at 2:02:04 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 don't have an opinion on the proposal itself (I honestly haven't thought
through the implications), but Gregory's point here is incredibly strong.
So +1 to due dilligence.
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141113/57c4085f/attachment.html>
More information about the Libraries
mailing list