Final bikeshedding call: Fixing Control.Exception.bracket

[Gregory Collins]

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.

G

On Thu, Nov 20, 2014 at 7:24 AM, Simon Marlow <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
> http://www.haskell.org/mailman/listinfo/libraries
>



-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141121/cee58be6/attachment-0001.html>