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

[VaclavKrpec at Eaton.com]

Hello Baruch,

thanks for your comment.
OK, I’ll just aim to create an implementation of all-purpose
portable clock with the possibility of monotonic/ real-time
operation (where available).
It still should be encapsulated, though.  Unlike time() and
difftime(), clock_*time() interface (or at least the monotonic
clock back-end) is not available everywhere.
If we want real portability, we need our own opaque type
and encapsulation of the implementation.

I guess I’ll just code a proposition and we shall se...

Regards,

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

________________________________


From: Baruch Even [mailto:baruch at ev-en.org]
Sent: Thursday, September 27, 2012 2:26 PM
To: Krpec, Vaclav
Cc: aquette.dev at gmail.com; nut-upsdev at lists.alioth.debian.org; clepple at gmail.com; baruch at debian.org
Subject: Re: [Nut-upsdev] NUT Bugs #313634 & #313714: unification & encapsulation of timer proposition


My opinion on this is that it might be a little too abstract. I'd go with what I essentially started which is to abstract just a monotonic clock with only what is needed. If the platform doesn't have a monitonic clock than it can be apprixmated.

This will also serve to explain the real intention of a monotonic clock and not just a plain timer.

My 2¢

Baruch
On Sep 27, 2012 1:19 PM, <VaclavKrpec at eaton.com<mailto:VaclavKrpec at eaton.com>> wrote:
Hello everybody,

I'm working on the "Use difftime for time comparison" bug (#313634).
Charles directed me to the other one "Use monotonic clock for monitoring"
attended to by Baruch; I believe that's very good idea, however I'd use a bit
more encapsulated & general approach:

1/ I'd create an opaque timer type and its get/set/cmp/inc/dec etc interface
under common
2/ implementation of the interface would use the monotonic clock if available
(the clock_*time on Linux, potentially other monotonic clock impl. on other
systems) and time_t as a fallback
3/ when implemented, use of the timer shall be spread throughout the code,
replacing direct use of time_t

What do you think?
I'm also a bit reluptant to do such a change in scope of the bugfix; I'd create
a new feature req. for that, OK?

Any comments/ suggestions welcome,

Regards,

Vaclav

P.S: already managed to post this from another address by mistake, so please
just discard the previous e-mail (or this one, depending on which you've read).

--
Václav Krpec
Software Developer
Network UPS Tools project
Eaton Opensource Team
Eaton European Innovation Center




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


_______________________________________________
Nut-upsdev mailing list
Nut-upsdev at lists.alioth.debian.org<mailto:Nut-upsdev at lists.alioth.debian.org>
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20121002/a540721a/attachment.html>