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