Final bikeshedding call: Fixing Control.Exception.bracket
Bardur Arantsson
spam at scientician.net
Thu Nov 20 09:52:54 UTC 2014
On 2014-11-20 00: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?
>
(Pardon me, if I'm talking nonsense, I have a nasty cold and my head
feels like it full of wool ATM.)
I would expect the "mask" to still be in effect again (atomically) when
"restore" returns, and thus the `onException ...` code should still be
covered by it. So unless "onException" itself is interruptible the above
version should be fine...?
At least that's what I convinced myself of before posting a very similar
question to yours.
Regards,
More information about the Libraries
mailing list