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:bar...@ev-en.org] Sent: Thursday, September 27, 2012 2:26 PM To: Krpec, Vaclav Cc: aquette....@gmail.com; nut-upsdev@lists.alioth.debian.org; clep...@gmail.com; bar...@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, <vaclavkr...@eaton.com<mailto:vaclavkr...@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@lists.alioth.debian.org<mailto:Nut-upsdev@lists.alioth.debian.org> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
_______________________________________________ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev