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:[email protected]] Sent: Thursday, September 27, 2012 2:26 PM To: Krpec, Vaclav Cc: [email protected]; [email protected]; [email protected]; [email protected] 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, <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
_______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
