[Nut-upsdev] NUT Bugs #313634 & #313714: unification & encapsulation of timer proposition

[Arnaud Quette]

2012/10/2 <VaclavKrpec at eaton.com>

>   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:baruch at ev-en.org]
> *Sent:* Thursday, September 27, 2012 2:26 PM
> *To:* Krpec, Vaclav
> *Cc:* aquette.dev at gmail.com; nut-upsdev at lists.alioth.debian.org;
> clepple at gmail.com; baruch at 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, <VaclavKrpec at 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 at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev****
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20121003/0ff662f3/attachment.html>