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

[VaclavKrpec at Eaton.com]

> From: Charles Lepple [mailto:clepple at gmail.com]
> On Oct 3, 2012, at 8:41 AM, <VaclavKrpec at Eaton.com> wrote:
> 
> > I see, however I think that it's actually better to do the encapsulation.
> > Justification:
> >
> > 1/ We need to alter widespread code, anyway (I mean if we used
> > clock_gettime already and just needed to implement it for platforms
> > that don't have it, using the autoconf macro would be nice and fast
> > way to do it, but since we don't, well, see point 2 and 3)
> 
> It would be nice if we could use the autoconf macro, but the problem is that we
> are not guaranteed to have the monotonic clock type just because we have
> clock_gettime().

Exactly.  My idea is to provide an interface that is capable of falling-back
to RTC if monotonic isn't available --- without the need of checking the
clock_gettime return value every time it's used.
Moreover, I agree with Arnaud that the clock_difftime function should
be able to accept NULL argument (either 1st or 2nd) to simplify
the typical usage (i.e. comparison with current time it'll get on its
own).
To be able to do that, I need my own type (so that I can store the clock
type) and therefore I need a new interface (ideally opaque).
That's about it, it's not too complicated :-)


> > But of course, I can just implement clock_gettime; however, I already
> > have the new module written, so I'd rather continue in this direction,
> > if you don't insist on it...
> > Note that I'm still on my branch so no harm done. ;-)
> 
> Your original timer abstraction sounded like it might need a lot of test code to
> go along with it. Please keep it simple, only implementing the interfaces that are
> necessary for now. I don't recall the state of unit test code in the NUT tree
> (there was a branch at one point), but this might be hard to debug if we don't
> have some simple test harnesses. After all, rolling the clock back (which is my
> understanding of what the monotonic clock interface guards against) is usually a
> privileged operation.

The interface (currently implemented) is attached; it's all wrapped around
portable implementation of nut_clock_gettime and matching nut_clock_difftime,
the rest are really straightforward wrappers/ macra.
Please let me know if you find it unfeasible.


> Since you're working for Eaton, Arnaud has the final word here, but speaking as
> someone who plans to review the code, this sounds to me like it is getting overly
> complicated.

The source code (implementation) has 168 lines, now, of which cca 60 are the wrappers.
Of course, only POSIX CLOCK_REALTIME, CLOCK_MONOTONIC, Linux-specific
CLOCK_MONOTONIC_RAW and time_t fallback are supported, now.
The idea is to add also mach_time.h implementation for Mac OSX, perhaps
use of gethrtime on Solaris for the monotonic clock etc...

vaclav



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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: clock.h
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20121003/66743898/attachment-0001.h>