* Bertram Felgenhauer <bertram.felgenha...@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? Roman _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
