Final bikeshedding call: Fixing Control.Exception.bracket
Yuras Shumovich
shumovichy at gmail.com
Thu Nov 13 09:59:31 UTC 2014
On Wed, 2014-11-12 at 19:40 -0800, Merijn Verstraaten 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.
How can it? takeMVar will not be interrupted because the mvar is full.
hClose performs other interruptible actions (like flushing internal
buffer,) but they seems to be correctly handled.
>
> Cheers,
> Merijn
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
More information about the Libraries
mailing list