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

Wed Oct 3 12:41:10 UTC 2012

Hi Arnaud,

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)

2/ Having our own interface provides more flexibility
(The implementation may actually not be really straightforward)

3/ We don’t mind performance loss on wrappers
(Not that it would be that great)

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

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: Arnaud Quette [mailto:aquette.dev at gmail.com]
Sent: Wednesday, October 03, 2012 2:00 PM
To: Krpec, Vaclav
Cc: baruch at ev-en.org; 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

2012/10/2 <VaclavKrpec at eaton.com<mailto: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...

another variation is to standardize on clock_gettime() / clockid_t, and to use AC_REPLACE_FUNC to provide it from NUT, if it's not avail. on the system.

tell me back if you need some guidance to check this variation.

cheers,
Arnaud
--
Linux / Unix / Opensource Engineering Expert - Eaton - http://opensource.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
From: Baruch Even [mailto:baruch at ev-en.org<mailto:baruch at ev-en.org>]
Sent: Thursday, September 27, 2012 2:26 PM
To: Krpec, Vaclav
Cc: aquette.dev at gmail.com<mailto:aquette.dev at gmail.com>; nut-upsdev at lists.alioth.debian.org<mailto:nut-upsdev at lists.alioth.debian.org>; clepple at gmail.com<mailto:clepple at gmail.com>; baruch at debian.org<mailto: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/20121003/260d5392/attachment-0001.html>