Final bikeshedding call: Fixing Control.Exception.bracket

[John Lato]

I don't think it matters that this refactor is not vulnerable to the same
issue.  The point was to demonstrate that bracket+hClose is not actually
guaranteed to close the resource.  I agree it's not a paragon of good
style, but it does demonstrate that there is an actual problem even with a
"simple" cleanup function.

John

On Thu Nov 13 2014 at 11:47:51 AM 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.
>
> 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/20141113/a1016731/attachment-0001.html>