Georg Köster wrote:
> The second implementation has clearly other troubles (I didn't see that 
> it's just using a LinkedList that's apparently not thread safe), but I 
> explained before that I believe at least the double signaling is dealt 
> with.

It most definitely does not prevent double signaling! What makes you 
think it does? It is easiest to see in the case where we first get a 
timeout signal, and then -while being inside #resumeProcess:- the "real" 
event. Obviously there is nothing in the implementation that prevents 
the second signal from occurring.

> I would recommend at least adding this problem to the documentation of 
> wait*, that if one of the timed waits is used the wait (without timeout) 
> contract is violated in that it might return even if no user process 
> sent a signal.

Well, duh. It is the very *definition* of waitTimeoutMSecs: that it may 
return although the event hasn't occurred. That's what the method does. 
The comment is explicit, too noting that  "It is up to the sender to 
determine the difference between the expected event and a timeout".

Cheers,
   - Andreas