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.