2012/10/2 <[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]] > *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]> 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] > 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
