|2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 <2012> 2013 2014 2015 2016 2017 2018 2019 2020||Index||2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 <2012> 2013 2014 2015 2016 2017 2018 2019 2020|
|<== Date ==>||<== Thread ==>|
|Subject:||RE: epicsTimer and rounding|
|From:||"Hill, Jeff" <email@example.com>|
|To:||Eric Norum <firstname.lastname@example.org>, Ralph Lange <Ralph.Lange@gmx.de>|
|Cc:||EPICS Core Talk <email@example.com>, Dirk Zimoch <firstname.lastname@example.org>|
|Date:||Fri, 8 Jun 2012 14:24:13 +0000|
Ø 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.