Concurrent Haskell, asynchronous exceptions and interruptibility (again)

[Simon Marlow]

> For Concurrent Haskell, with respect to asynchronous=20
> exceptions, can a=20
> thread receive an asynchronous exception if it's evaluating=20
> an expression=20
> that could "potentially block on IO" when evaluated within=20
> the "block"=20
> function?
>=20
> Specifically, is interruptibility determined statically in=20
> the language definition or dynamically at run time?

"dynamically at runtime", according to the semantics given in our paper.
GHC does actually implement this, although it implements a slightly
different version of throwTo from the one described in the paper (ours
blocks until the exception has been delivered).

> For example, assume a thread is evaluating the following function.
>=20
> transfer :: MVar a -> IO (MVar a)
> transfer from =3D
>     block $ do
>         to <- newEmptyMVar
>         x <- takeMVar from
>         putMVar to x
>         return to
>=20
> In general, since putMVar is an IO function, it can=20
> potentially block (if=20
> its MVar argument is already occupied with a value). However,=20
> since "MVar=20
> to" will obviously be vacant in this instance, the putMVar=20
> can not block on=20
> IO.
>=20
> Would ghc allow an asynchronous exception to be raised at the=20
> point that "putMVar to x" is evaluated?

Not unless the putMVar blocks.  The proof that it never blocks depends
on the behaviour of other threads though: if you have another thread
doing putMVar on the same MVar, then it may block.  Other threads must
be "well-behaved" for it to work.

> If not, then I guess transfer is exception safe.
>=20
> Would that answer scale? Could I replace the "putMVar to x" with an=20
> arbitrarily large/complex IO function that I might write that=20
> is guaranteed=20
> (by me at least) to be non-blocking and still be sure that an=20
> exception=20
> would not be delivered during evaluation of that function?

Yes.

Cheers,
	Simon