Final bikeshedding call: Fixing Control.Exception.bracket

[Eric Mertens]

If the hClose is interrupted it will fall to the GC to close the handle in
the finalizer for the handle.

On Sun, Nov 23, 2014, 9:46 AM John Lato <jwlato at gmail.com> wrote:

> On Sun Nov 23 2014 at 7:09:10 AM Simon Marlow <marlowsd at gmail.com> wrote:
>
>> On 21/11/14 17:22, Gregory Collins wrote:
>> > New post from Yuras provides food for thought:
>> > https://github.com/Yuras/io-region/wiki/Handling-%28async%
>> 29-exceptions-in-haskell:-pushing-bracket-to-the-limits
>> >
>> > In particular he points out a case for which uninterruptibleMask will
>> > cause unkillable threads: let's say hClose blocks flushing the output to
>> > a file, but the write fails because of a hardware error and blocks
>> > forever. (Alternatively, imagine the file is on NFS and you get a cable
>> > cut between the two machines). The thread executing hClose in the
>> > cleanup action becomes unkillable.
>>
>> Yes, and furthermore hClose is not "buggy": even if it is interrupted by
>> an async exception, the file descriptor will still be closed by the
>> finalizer.  This is not something you want to do a lot, of course, but
>> as a backup plan for the rare case of an async exception killing the
>> cleanup action it's fine.
>>
>
> This is not entirely correct.  If another thread is holding the MVar when
> hClose is called, and it is blocked in takeMVar, if an async exception
> arrives takeMVar will be interrupted and the file descriptor will never be
> closed.  Arguably that situation shouldn't happen except in poorly-designed
> programs, but I can provide at least one example where it appears to be a
> viable architecture, and I'm not convinced it would never happen in
> practice.
>
>
>> So arguably uninterruptibleMask is not what we want for hClose.
>>
>
> Is there any way to fix the issue I describe besides preventing async
> exceptions from arising while blocked on the MVar?  Although I do agree we
> don't want to put uninterruptibleMask inside hClose (long ramble at
> http://johnlato.blogspot.ca/2014/11/exception-handling-and-cleanup.html)
>
> John
>
>
>>
>> Cheers,
>> Simon
>>
>>
>> > G
>> >
>> > On Thu, Nov 20, 2014 at 7:24 AM, Simon Marlow <marlowsd at gmail.com
>> > <mailto:marlowsd at gmail.com>> wrote:
>> >
>> >     On 19/11/2014 23:07, Ganesh Sittampalam wrote:
>> >
>> >         On 13/11/2014 10:44, Simon Marlow wrote:
>> >
>> >             On 13/11/2014 07:47, Merijn Verstraaten wrote:
>> >
>> >
>> >                 A new version would look like:
>> >
>> >                 bracket before after thing =
>> >                      mask $ \restore -> do
>> >                        let atomicAfter = uninterruptibleMask . after
>> >                        a <- before
>> >                        r <- restore (thing a) `onException` atomicAfter
>> a
>> >                        _ <- atomicAfter a
>> >                        return r
>> >
>> >                 Slightly different versions are possible and the other
>> >                 relevant
>> >                 bracketing functions mentioned in this thread can be
>> >                 treated similarly.
>> >
>> >
>> >             Since we would need this for catch too, the sensible thing
>> >             to do (if we
>> >             decide to go ahead with this) would be to change the
>> >             implementation of
>> >             catch in the RTS from masking the exception handler to
>> >             uninterruptibleMask.  That would mean that at least for
>> >             catch there
>> >             would be no additional overhead, and it would make the
>> >             modifications to
>> >             the other operations simpler in some cases.
>> >
>> >
>> >         If this isn't done in the RTS, is there a possibility of an
>> async
>> >         exception slipping in between the exception handler starting
>> and the
>> >         uninterruptibleMask starting?
>> >
>> >
>> >     No, because the exception handler is masked.
>> >
>> >     Cheers,
>> >     Simon
>> >
>> >     _________________________________________________
>> >     Libraries mailing list
>> >     Libraries at haskell.org <mailto:Libraries at haskell.org>
>> >     http://www.haskell.org/__mailman/listinfo/libraries
>> >     <http://www.haskell.org/mailman/listinfo/libraries>
>> >
>> >
>> >
>> >
>> > --
>> > Gregory Collins <greg at gregorycollins.net <mailto:greg at gregorycollins.
>> net>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141123/745ea917/attachment-0001.html>