Final bikeshedding call: Fixing Control.Exception.bracket

[John Lato]

Just for clarification, what's up for discussion at this point?  Is
everyone at least convinced that the status quo is untenable, and we're
trying to achieve consensus (or at least a mandate) on a solution?

As for current solutions, I think #2 is best.  Functions like bracket need
to "just work" in general.

On Tue Nov 11 2014 at 10:18:50 AM David Feuer <david.feuer at gmail.com> wrote:

> I like #2. Errors you can detect easily are much better than errors that
> silently mess things up.
> On Nov 11, 2014 1:10 PM, "Merijn Verstraaten" <merijn at inconsistent.nl>
> wrote:
>
>> Ola!
>>
>> In September Eyal Lotem raised the issue of bracket's cleanup handler not
>> being uninterruptible [1]. This is a final bikeshedding email before I
>> submit a patch.
>>
>> The problem, summarised:
>> Blocking cleanup actions can be interrupted, causing cleanup not to
>> happen and potentially leaking resources.
>>
>> Main objection to making the cleanup handler uninterruptible:
>> Could cause deadlock if the code relies on async exceptions to interrupt
>> a blocked thread.
>>
>> I count only two objections in the previous thread, 1 on the grounds that
>> "deadlocks are NOT unlikely" and 1 that is conditioned on "I don't believe
>> this is a problem".
>>
>> The rest seems either +1, or at least agrees that the status quo is
>> *worse* than the proposed solution.
>>
>> My counter to these objections is:
>> 1) No one has yet shown me any code that relies on the cleanup handler
>> being interruptible
>>
>> 2) There are plenty of examples of current code being broken, for example
>> every single 'bracket' using file handles is broken due to handle
>> operations using a potentially blocking MVar operation internally,
>> potentially leaking file descriptors/handles.
>>
>> 3) Even GHC-HQ can't use bracket correctly (see Simon's emails)
>>
>> 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.
>>
>> Trade-offs:
>> Solution 1 won't change the semantics of any existing code, however this
>> also means that any currently broken uses of bracket will remain broken,
>> possibly indefinitely.
>>
>> Solution 2 will change the semantics of bracket, which means any
>> currently broken uses of bracket will be fixed, at the cost of creating
>> potential deadlocks in code that relies on the interruptibility of cleanup.
>>
>> I will argue that solution #2 is preferable, since I have yet to see any
>> code that uses the interruptibility of the cleanup handler. Whereas there's
>> many broken assumption assuming the cleanup handler is not interruptible.
>>
>> Secondly, it is easier to detect deadlocks caused by this problem than it
>> is to detect resource leaks which only happen in unlucky timings of async
>> exceptions. Especially since any deadlock caused by the change can be fixed
>> by replacing bracket with bracketInterruptible.
>>
>> [1] -
>> https://www.haskell.org/pipermail/libraries/2014-September/023675.html
>>
>> Cheers,
>> Merijn
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141111/c2dd2d7b/attachment-0001.html>