On Sun Nov 23 2014 at 7:09:10 AM Simon Marlow <marlowsd@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@gmail.com
> <mailto:marlowsd@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@haskell.org <mailto:Libraries@haskell.org>
>     http://www.haskell.org/__mailman/listinfo/libraries
>     <http://www.haskell.org/mailman/listinfo/libraries>
>
>
>
>
> --
> Gregory Collins <greg@gregorycollins.net <mailto:greg@gregorycollins.net>>

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries