asynchronous exceptions

On 07 April 2006 00:36, Marcin 'Qrczak' Kowalczyk wrote:
> "Simon Marlow" <simonmar at microsoft.com> writes:
>> I agree with your assessment of the problems with interruptible
>> operations in GHC: that it is impossible to completely block async
>> exceptions across a computation. We could certainly add a way to
>> do this. Is that the substance of your objection to GHC's async
>> exception mechanism?
>> Regarding interruptible operations, this and one more thing that I
> haven't written there:
>> The fact that some function uses an interruptible operation internally
> is a visible aspect of its behavior, both in GHC design and in mine.
I don't consider this to be a problem. Every API call you make has the
potential to throw exceptions, and since we don't usually go to the
trouble of documenting every exception that every library function can
raise, the caller always has to be prepared to handle arbitrary
exceptions thrown by calls to library functions. Asynchronous
exceptions thrown by interruptible operations just fall into this
category.
BTW, I just realised a better way to express block. If block is
supposed to count nesting, then we have a problem that you can still
unblock exceptions even within a block by using sufficient number of
unblocks, so the right way is to give block this type:
block :: ((IO b -> IO b) -> IO a) -> IO a
you use it like this:
block $ \restore ->
(do x <- takeMVar m
restore (...) `catch` \e -> ...)
so the only way to unblock is to restore the state of an enclosing
block. Returning the restore function and using it outside the block
isn't dangerous, so we don't have to play any quantified type games to
prevent that.
Cheers,
Simon