Final bikeshedding call: Fixing Control.Exception.bracket

[Yuras Shumovich]

On Wed, 2014-11-12 at 19:53 -0800, Merijn Verstraaten wrote:
> > On 12 Nov 2014, at 19:47, Eric Mertens <emertens at gmail.com> wrote:
> > 
> > It's not vulnerable to the same issue because hClose can't block (as far as I know) because it can't be in use at the time that clean up is running.
> 
> Ah, you're right, but that's just because in this case it was possible to redesign the code not to expose the Handle. However, the fact that this happens to be possible in this small test program, doesn't guarantee all programs can be restructured this way (me and Eyal have both run into situations where we couldn't).

Sorry, I missed this email initially, so please ignore my question in
the email I just sent.

> 
> Additionally, the only reason you know this is safe is because you've inspected (or assumed) the code dealing with handles and hClose and have checked that it isn't somehow sharing the Handle behind your back. Unless you propose every person always makes this analysis for any IO allocation operations they use (I hope not!), this remains an issue. 

You continue referring to this issue, but I still don't understand it.
Could you please elaborate it?
There docs are clear: there is a list of uninterruptible actions, and
you should assume all other actions interruptible. So that hClose -- no
need to inspect anything.
And hClose tries hard to close file descriptor in case of exception
(sync or async). It is bug in hClose, not in bracket, if it fails to
close the descriptor.

> 
> Cheers,
> Merijn
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries