[Haskell] What guarantees (if any) do interruptible operations have in presence of asynchronous exceptions?

[Cat Dancer]

On 12/5/06, Chris Kuklewicz <haskell at list.mightyreason.com> wrote:
> Making small programs to test these properties is a good sanity check.  For
> instance I just leaned that "safePoint = unblock ( return () )" does not work.

Maybe if you do something to allocate some memory inside of the unblock?


> > If this were true, then if you caught an asynchronous exception from
> > the putMVar operation, you'd know that a value was not put into the
> > MVar by the operation.
>
> I think that should be a safe assumption when running under "block".

"I think" and "should be" is nice, how do we find out if it's really
true -- for sure?


> > Then it would be easy to program with MVar's in the presence of
> > asynchronous exceptions.  When you caught an asynchronous exception,
> > you could set a flag, and then redo the putMVar.
>
> If you call that "easy" then sure.
>
> > For STM, is "atomically" an interruptible operation?  If it is, what
> > guarantees does it offer in the presence of asynchronous exceptions?
>
> "block (atomically stm)" is interruptible when the operation "stm" uses retry
> and perhaps when it has to be re-attempted due to conflicting updates.  If it
> runs without conflict and commits then it cannot be interrupted by an async
> exception.
>
> If (atomically stm) is interrupted then it is rolled back and will have had no
> visible side effects.

Easy in the sense that the pattern of "trying an operation, setting a
flag if an asynchronous exception is raised, and redoing the
operation" can be encapsulated in a function.

That function can then be used with any interruptible operation (such
as putMVar, or atomically, or accept) *if* the operation guarantees
that inside of a "block" it will either perform its operation, or
interrupt and allow an asynchronous to be raised, but not both.