2012/10/3 <[email protected]> > Hi Arnaud,**** > > ** >
Hi Vaclav, > 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. ;-) > works for me, all-in to see ;) 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:* 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]>**** > > 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
