Final bikeshedding call: Fixing Control.Exception.bracket

[Eric Mertens]

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.

On Wed, Nov 12, 2014 at 7:40 PM, Merijn Verstraaten <merijn at inconsistent.nl>
wrote:

>
> > On 12 Nov 2014, at 19:17, Eric Mertens <emertens at gmail.com> wrote:
> > First let's have a discussion about whether or not that program *should*
> have worked as written. It isn't immediately obvious that Handles should be
> closed out from under other threads that are using them like that. I
> certainly try to avoid it.
>
> No, let's NOT discuss that. The documented behaviour for handles is that
> if closed in one thread, they become invalid in all threads. This also
> mimics the behaviour of FILE* in C and more importantly, while I agree that
> this design is not nice, solving it in a nice way is an open problem.
>
> So let's not get sidetracked with a discussion of what Handle semantics
> should be in an ideal world. In the current real world if a programmer
> writes "hClose", let's assume he/she intends to close the Handle.
>
> > For example, we could modify the program like this so that the thread
> was responsible for cleaning up its own resources.
>
> Your version is susceptible to the exact same problem we're discussing. If
> the "release" action blocks (as, for example, hClose potentially does) it
> can be interrupted and aborted.
>
> Cheers,
> Merijn
>
>


-- 
Eric Mertens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141112/2fda4907/attachment.html>