Comment 9 for bug 1861612

Well, in both cases (HIGH delays and callbackRequestDelay) we seem to have a threshold for the requested delay with a response switching between a 1 tick delay and a 0 tick delay.

Even with your statement
> ...seems to take a random amount of time between 0 and 0.01666 seconds.
> This is exactly what I expect if the delay does wait for the next
> clock tick, just like epicsThreadSleep.

I have to say that I do not like that behavior. Agreed that it may only play out in few real life use cases, a delay API that cannot promise the delay seems awkward and wrong. Note that for any delay request, a system with a clock tick larger than the requested delay will response with an arbitrary delay between zero and one clock tick, which is unrelated to the requested value.

Much like the fundamental difference between a "snooze" timer (don't wake me up before...) and an alarm setting (wake me up no later than...) the use cases for a delay and a timer are different and the API promises should reflect that.

IMHO: A requested delay > 0 shall never call back before the requested delay has passed. If waiting for the next system tick comes back too early, delay shall wait for another system tick.
Immediate call back is acceptable (and somewhat expected) for a requested delay = 0.