[Nut-upsdev] NUT Bugs #313634 & #313714: unification & encapsulation of timer proposition

[VaclavKrpec at Eaton.com]

Hello Charles,

you can take a look at the code in branches/Vaclav/common/clock.c vi viewvc.

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?

THanks,

vasek



> 

-----------------------------
Eaton Elektrotechnika s.r.o. ~ S�dlo spolecnosti, jak je zaps�no v rejstr�ku: Kom�rovsk� 2406, Praha 9 - Horn� Pocernice, 193 00, Cesk� Republika ~ Jm�no, m�sto, kde byla spolecnost zaregistrov�na: Praha ~ Identifikacn� c�slo (ICO): 498 11 894 
-----------------------------

-----Original Message-----
> From: Charles Lepple [mailto:clepple at gmail.com]
> Sent: Monday, October 08, 2012 2:36 PM
> To: Krpec, Vaclav
> Cc: Arnaud Quette; Emilien KIA; nut-upsdev at lists.alioth.debian.org List
> Subject: Re: [Nut-upsdev] NUT Bugs #313634 & #313714: unification &
> encapsulation of timer proposition
> 
> [adding nut-upsdev back to CC list.]
> 
> > While you at it --- I've written the nut_clock_gettime POSIX
> > implementation so that fallback from monotonic POSIX clock impl. to
> > RTC is actually also done if the system defines _POSIX_MONOTONIC_CLOCK
> > macro, but the call ends with EINVAL (i.e. not implemented) if monotonic clock
> is requested.
> > I thought that may be a bit over-protective; as soon as the OS defines
> > the detection macro, we should be entitled to expect it to work;
> > EINVAL should therefore be considered an error and propagated.
> 
> I'm confused. Could you post pseudocode, or the actual patch, for what is being
> described above?
> 
> --
> Charles Lepple
> clepple at gmail
> 
>