I was looking thru the code for the posix version of the WaitableEvent::wait function today and I wonder if it has a bug, or I just don’t understand it. If the call to pthread_cond_timedwait returns due to what the docs refer to as a ‘spurious wakeup’ (and what the !es->triggered loop protects against), then the timeout will be recalculated in full, not taking into account any time already spent waiting, and thus the wait could end up more than timeout supplied, yes? no?
hmm… that’s a good point. It does look like the time calculation should be outside the loop. Thanks, I’ll take a serious look at that.
actually, I think the calculation should be inside the loop, but the time-passed since entering the timedwait should be subtracted (and tested) each iteration.
No, you were right the first time. pthread_cond_timedwait takes an absolute time, so it should calculate that at the start, and re-use it in the loop. Probably very unlikely to ever cause an issue, but I’ll tidy it up.
oh, it’s absolute time, then it’s not really a bug, just a little extra work being done… good to fix it though…