Experimental Physics and
Industrial Control System

Ø  The posix implementation of epicsThreadSleep calls nanosleep

Ø  asking for a 0 delay, and gets a 0 delay.

 

This is certainly inconsistent with the windows implementation which (intends) to round

any floating point seconds sleep requested of less than one tick to a tick. Rounding sleeps

of between 0 and .5 seconds to no sleep definitely seems wrong to me. We should probably

clarify what behavior should be implemented by each OS specific stub in the application

developers guide, and then make all of them consistent?

 

Ø  I've never encountered a 'sleep/pause/nap/delay' function that could return early.

 

Next question; If we decide that a sleep of less than one tick should be a sleep of one tick, then

perhaps Ralph’s issue is arguably caused by an issue in the posix implementation of

epicsThreadSleep instead of in epicsTimer. Fixing only posix timer (and any other inconsistent

implementations) would presumably be an optimal solution where Ralph’s issue is solved and

also periodic timers can remain more statistically accurate (on average)? Note that the epicsTimer

class _is_ used to schedule the scan threads, ca beacons, etc.

 

I will certainly go with whatever the consensus ends up being.

 

Jeff