Re: callbackRequestDelayed question

[Michael Davidsaver via Core-talk <core-talk at aps.anl.gov>]

On 11/12/25 2:14 PM, Mark Rivers wrote:

...

But more importantly for me callbackRequestDelayed returns immediately for all delays less than 10 ms.  It’s hard to believe it is a coincidence that epicsThreadSleepQuantum() is 10 ms.  It thus appears to me that if the requested delay is less than epicsThreadSleepQuantum() then callbackRequestDelayed returns immediately.  Is that true?

The epicsTimer code is a little hard to follow, but I think yes.  More precisely, the timer is queued with a delay of 0, so it expires as soon as the worker thread wakes up.

 

The most recent Application Developer’s Guide says this:

 

epicsTimerQueueNotify:: quantum

The virtual function epicsTimerQueueNotify::quantum() returns the timer expire interval scheduling quantum in seconds. This allows different types of timer queues to use application specific timer expire delay scheduling policies. The implementation of epicsTimerQueueActive employs epicsThreadSleep() for this purpose, and therefore epicsTimerQueueActive::quantum() returns the returned value from epicsThreadSleepQuantum(). Other types of timer queues might choose to schedule timer expiration using specialized hardware interrupts. In this case epicsTimerQueueNotify::quantum() might return a value reflecting the precision of a hardware timer.

To the best of my understanding, epicsTimer does not do any kind of quantization beyond scaling floating point second to integer ticks.  So I think the paragraph is a bit vague, and not especially accurate wrt. the current implementation.

 If unknown, then epicsTimerQueueNotify::quantum() should return zero.

At present, only windows could return zero.  If something when wrong, RTEMS or vxWorks would return NaN.  On Linux whatever the kernel provides will be returned, which for some time has been a non-zero constant.

 

Is it possible to override the value for epicsThreadSleepQuantum()?

No.