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:[email protected]] Sent: Wednesday, October 03, 2012 2:00 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 2012/10/2 <[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>] Sent: Thursday, September 27, 2012 2:26 PM To: Krpec, Vaclav Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[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
