Experimental Physics and
Industrial Control System

"J. Lewis Muir" <[email protected]> · Thu, 13 Nov 2014 17:27:48 -0600

On 11/13/14 4:57 PM, Michael Davidsaver wrote:
> Strictly speaking epicsTimeGetCurrent() does try to prevent backwards
> jumps.  Subsequent calls should never return later values.  Of course
> in some cases this means that time stops...

Hi, Michael.

Thank you for your reply.  I see; I didn't know that epicsTimeGetCurrent
prevents backward jumps, but I guess this is probably what Kay was
alluding to when she mentioned that "generalTimeGetExceptPriority()
checks for monodic behavior."

So, I guess I should clarify that I'm interested in something like
POSIX's clock_gettime using the CLOCK_MONOTONIC clock ID.

Still, as you noted, epicsTimeGetCurrent can result in time that stops
and, in my example, an actual timeout that is longer than what the
caller requested, whereas a POSIX CLOCK_MONOTONIC clock would not have
that problem.

> I think it wouldn't be difficult to add a real monotonic time source
> which defaults to epicsTimeGetCurrent() for platforms without such a
> time source.  POSIX has clock_gettime w/ CLOCK_MONOTONIC and similar
> (RTEMS implements this).  Windows has something as well.  Not sure
> about vxWorks.

PEP 418, while obviously for Python, does include an overview of time
functions available on different operating systems as well as some
references on the subject, so it might be a help for implementing this
on other platforms supported by EPICS:

  http://legacy.python.org/dev/peps/pep-0418/

> https://bugs.launchpad.net/epics-base/+bug/1392516

Thanks for creating that!

Regards,

Lewis

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System