roma at ro-che.info
Sun Jul 28 18:47:59 CEST 2013
* Bertram Felgenhauer <bertram.felgenhauer at googlemail.com> [2013-07-28 17:57:04+0200]
> Roman Cheplyaka wrote:
> > The documentation for throwTo says:
> > throwTo does not return until the exception has been raised in the
> > target thread. The calling thread can thus be certain that the target
> > thread has received the exception. This is a useful property to know
> > when dealing with race conditions: eg. if there are two threads that
> > can kill each other, it is guaranteed that only one of the threads
> > will get to kill the other.
> > I don't see how the last sentense follows.
> I agree that it does not follow logically, at least I don't see how.
> It is an additional guarantee that the implementation provides.
> > I understood it so that the implication
> > throwTo has returned => exception has been delivered
> > is true, but not the reverse. If my understanding is correct, then both
> > exceptions could be delivered without any of throwTos returning.
> > Or is it true that
> > throwTo has returned <=> exception has been delivered
> Yes, that's true, in the sense that if and only if the exception
> has been delivered, the thread is ready to run (i.e., not blocked),
> to continue right after the throwTo.
> The implication from left to right does not mean that the thread
> ever gets a chance to run again. The program may terminate, or
> the thread may receive another exception in the meantime. The
> latter can be prevented by masking exceptions.
> I hope that makes sense.
Thanks Bertram, this makes perfect sense. I wonder if the docs should be
updated to clarify this?
More information about the Glasgow-haskell-users