Comment 22 for bug 1861612

I'll try to summarize some thoughts and discussions of the past 2 days or so.
Some of this is (I think) reiterating what Andrew has written. I'm repeating
it to hopefully demonstrate that I understand it.

1. epicsEventWaitWithTimeout() doesn't function as specified on RTEMS, vxWorks, or Windows.

With RTEMS and vxWorks I think this can be understood if the integer delay N underlying primitives
rtems_semaphore_obtain() or semTake() block until the Nth tick of timer (interrupt). So a call with delay of one may timeout almost immediately if made just before a tick.

So a timeout of N may result in times between T*(N-1) and T*N where T is the tick timer interval.

This functions like a truncation, but is separate, and cumulative to the truncation/rounding done in epicsEventWaitWithTimeout() converting floating point seconds to ticks.

So the minimal change to ensure epicsEventWaitWithTimeout() behaves as specified (timeout after >=delay) involves a float to int conversion like:

> double delay = ...;
> unsigned ticks = tickRate * delay;
> ticks += 2;

2. There may be more than one issue involved.

epicsEventWaitWithTimeout() was not affected by 4f2228fb1d7527fb5ebc8b2d747c309f1dd7698d.
The effect of this commit on the timer queue which Mark reports is (I think) in changing the delay values passed to epicsEventWaitWithTimeout(). It is not known whether these delay values would produce the correct behavior if epicsEventWaitWithTimeout() functioned as specified.

I think this question could be answered using an RT linux or RTEMS5 system with a software DAC and an oscilloscope.

3. Windows is peculiar

The Windows impl. uses WaitForSingleObject() which takes a timeout in milli-seconds,
but seems to behave as if it were internally doing a similar truncation.
The delays I've observed seem to be round down to multiples of epicsThreadSleepQuantum().

4. Quantization of monotonic time effecting epicsEventTest

epicsEventTest on Windows is sometimes reporting measured delays of exactly zero.
I think this is due to effective delays being less than the monotonic time quantum,
which is reported as 1ms for the appveyor builds. epicsEventTest tries to test down
to the 10's of microseconds.