Final bikeshedding call: Fixing Control.Exception.bracket

[Bardur Arantsson]

On 2014-11-11 19:09, Merijn Verstraaten 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.
> 
> 

+2 to #2

Like you said, I don't think any evidence (of *real programs*) was
presented in the original thread where this would be a worse problem
than a reasource leak is. And deadlocks are actually things that show up
*immediately* for the one experiencing the deadlock whereas resource
leaks show up thousands of client requests (or whatever) later.