[Nut-upsdev] NUT Bugs #313634 & #313714: unification & encapsulation of timer proposition
Charles Lepple
clepple at gmail.com
Tue Oct 9 12:48:48 UTC 2012
On Mon, Oct 8, 2012 at 8:57 AM, <VaclavKrpec at eaton.com> wrote:
> Hello Charles,
>
> you can take a look at the code in branches/Vaclav/common/clock.c vi viewvc.
Oh, I thought you were referring to a later revision than what was
checked into SVN.
> Clarification: I do clock_gettime(CLOCK_MONOTONIC, &tm) and if that
> fails with EINVAL and the user requested MONOTONIC_PREF (i.e. fall-back
> to RTC is allowed), I do another clock_gettime(CLOCK_REALTIME, &tm)
> which should always work.
>
> However, I wonder whether this isn't too cautions; accordingly to the man,
> as long as _POSIX_MONOTONIC_CLOCK macro is defined, CLOCK_MONOTONIC
> is available.
> On the other hand, build on HPUX prooved that this may not be true;
> HPUX 11 defines _POSIX_MONOTONIC_CLOCK, but apparently doesn't define
> CLOCK_MONOTONIC.
> I mean, if this is possible, then it might also be possible that CLOCK_MONOTONIC
> is defined, but the call fails... The question is how pedantic/ paranoid should I be?
I don't think we should ignore an EINVAL error, and we should fall
back to gettimeofday() in that case. (I know gettimeofday is
deprecated, but if CLOCK_MONOTONIC isn't quite right, then
gettimeofday should work.)
--
- Charles Lepple
More information about the Nut-upsdev
mailing list