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

[VaclavKrpec at Eaton.com]

> > 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.)

Thanks for the comment, Charles, but I ment something a little bit different.
However, to your comments:

1/ I completely agree that we must not ignore clock_gettime return value
(I mean it's part of the iface, isn't it); however, POSIX states quite clearly
that CLOCK_REALTIME implementation is mandatory; I believe that we can
rely on the RTC existence as long as _POSIX_TIMERS > 0.
(At least this appears to be respected throughout all the platforms.)
If POSIX clock iface isn't available, I believe that falling back to plain old
C89 time_t is the bes solution since using an obsolete iface simply means
that we'll have to abandon it sooner or later and, since gettimeofday
isn't monotonic, it doesn't have any added value (we don't really care
about seconds fractions, do we).

2/ My comment was targeting the problem with the other (various) possible
implementations.
If you take a look at the clock_gettime interface, you'll find out that it is
actually a little bit schizophrenic: at the same time, it says that the system
may define various macra identifying different clock implementations
AND if you actually specify the clock to the clock_gettime call, it may fail
with EINVAL, which means that the clock with the id isn't implemented.
I mean, why should the system #define a CLOCK_? id and then do not have
an appropriate implementation?
This appears to be a bit over-designed to me; either the system defines
clock ids, symbolically, and implements all of them, or the clock ids
should be standardised in a cross-platform header file and the systems
may or may not define them, notifying the caller via the return code.
However, having both seems a bit redundant to me.

So, my implementation covers both the static and dynamic clock
availability checking; on compile time, it checks whether the most
appropriate clock id is defined (CLOCK_MONOTONIC_RAW on Linux,
CLOCK_MONOTONIC on POSIX with monotonic clock).
Maybe I could actually add a sanity check for CLOCK_REALTIME,
why not, but I guess that that would indeed be paranoid.

On run-time, if CLOCK_MONOTONIC(_RAW)? is requested,
I can still fall-back to CLOCK_REALTIME if the caller doesn't
insist on using monotonic clock.
That's the current implementation.

However, my concern was if this is not too paranoid and complicated.
If the OS #defines the clock id, it should implement the clock.
That seems logical to me, however, maybe it would be too
optimistic to assume that...  And this is the point at which I asked
for the consult; how paranoid should I be?
By default I'm quite paranoid, you know... ;-)
But it's also not that good to fill the tree with potentially unnecessary code.

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 
-----------------------------