> For Concurrent Haskell, with respect to asynchronous
> exceptions, can a
> thread receive an asynchronous exception if it's evaluating
> an expression
> that could "potentially block on IO" when evaluated within
> the "block"
> function?
>
> Specifically, is interruptibility determined statically in
> 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.
>
> transfer :: MVar a -> IO (MVar a)
> transfer from =
> block $ do
> to <- newEmptyMVar
> x <- takeMVar from
> putMVar to x
> return to
>
> In general, since putMVar is an IO function, it can
> potentially block (if
> its MVar argument is already occupied with a value). However,
> since "MVar
> to" will obviously be vacant in this instance, the putMVar
> can not block on
> IO.
>
> Would ghc allow an asynchronous exception to be raised at the
> 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.
>
> Would that answer scale? Could I replace the "putMVar to x" with an
> arbitrarily large/complex IO function that I might write that
> is guaranteed
> (by me at least) to be non-blocking and still be sure that an
> exception
> would not be delivered during evaluation of that function?
Yes.
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
