Final bikeshedding call: Fixing Control.Exception.bracket

[David Feuer]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141111/59f08491/attachment.html>