Hi Vasek<br><br><div class="gmail_quote">2012/10/8  <span dir="ltr"><<a href="mailto:VaclavKrpec@eaton.com" target="_blank">VaclavKrpec@eaton.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello Charles,<br>
<br>
you can take a look at the code in branches/Vaclav/common/clock.c vi viewvc.<br>
<br>
Clarification: I do clock_gettime(CLOCK_MONOTONIC, &tm) and if that<br>
fails with EINVAL and the user requested MONOTONIC_PREF (i.e. fall-back<br>
to RTC is allowed), I do another clock_gettime(CLOCK_REALTIME, &tm)<br>
which should always work.<br>
<br>
However, I wonder whether this isn't too cautions; accordingly to the man,<br>
as long as _POSIX_MONOTONIC_CLOCK macro is defined, CLOCK_MONOTONIC<br>
is available.<br>
On the other hand, build on HPUX prooved that this may not be true;<br>
HPUX 11 defines _POSIX_MONOTONIC_CLOCK, but apparently doesn't define<br>
CLOCK_MONOTONIC.<br>
I mean, if this is possible, then it might also be possible that CLOCK_MONOTONIC<br>
is defined, but the call fails...  The question is how pedantic/ paranoid should I be?<br></blockquote><div><br>The below link will provide you a good summary of the situation, what we can do and how.<br><br>AFAICT, there is no way on HPUX (and some other older Unix) to use clock_gettime with CLOCK_MONOTONIC, but CLOCK_REALTIME (which is functionally different).<br>
gethrtime (high resolution time) seems to be the fallback here:<br><a href="http://nadeausoftware.com/articles/2012/04/c_c_tip_how_measure_elapsed_real_time_benchmarking">http://nadeausoftware.com/articles/2012/04/c_c_tip_how_measure_elapsed_real_time_benchmarking</a><br>
<br>but this requires (for HPUX) the native compiler and CFLAGS set to "Extended Ansi" mode...<br>so there is a 2nd (more general) fallback, using... gettimeofday! :-/<br><br>Another reading on configure checks:<br>
<a href="http://www.nco.ncep.noaa.gov/pmb/codes/nwprod/gempak/nawips2/extlibs/glib/v2.15.6/configure.in">http://www.nco.ncep.noaa.gov/pmb/codes/nwprod/gempak/nawips2/extlibs/glib/v2.15.6/configure.in</a><br><br>As a separate comment, here is the list of remaining gettimeofday:<br>
common/common.c:        gettimeofday(&now, NULL);<br>drivers/bcmxcp_usb.c:    gettimeofday(&start_time, NULL);<br>drivers/bcmxcp_usb.c:            gettimeofday(&now, NULL);<br>drivers/dstate.c:    gettimeofday(&now, NULL);<br>
drivers/main.c:        gettimeofday(&timeout, NULL);<br>drivers/usbhid-ups.c:    gettimeofday(&now, NULL);<br><br>cheers,<br>Arnaud<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im HOEnZb">
-----Original Message-----<br>
> From: Charles Lepple [mailto:<a href="mailto:clepple@gmail.com">clepple@gmail.com</a>]<br>
</div><div class="im HOEnZb">> Sent: Monday, October 08, 2012 2:36 PM<br>
> To: Krpec, Vaclav<br>
</div><div class="im HOEnZb">> Cc: Arnaud Quette; Emilien KIA; <a href="mailto:nut-upsdev@lists.alioth.debian.org">nut-upsdev@lists.alioth.debian.org</a> List<br>
> Subject: Re: [Nut-upsdev] NUT Bugs #313634 & #313714: unification &<br>
> encapsulation of timer proposition<br>
><br>
</div><div class="HOEnZb"><div class="h5">> [adding nut-upsdev back to CC list.]<br>
><br>
> > While you at it --- I've written the nut_clock_gettime POSIX<br>
> > implementation so that fallback from monotonic POSIX clock impl. to<br>
> > RTC is actually also done if the system defines _POSIX_MONOTONIC_CLOCK<br>
> > macro, but the call ends with EINVAL (i.e. not implemented) if monotonic clock<br>
> is requested.<br>
> > I thought that may be a bit over-protective; as soon as the OS defines<br>
> > the detection macro, we should be entitled to expect it to work;<br>
> > EINVAL should therefore be considered an error and propagated.<br>
><br>
> I'm confused. Could you post pseudocode, or the actual patch, for what is being<br>
> described above?<br>
><br>
> --<br>
> Charles Lepple<br>
> clepple@gmail<br>
><br>
><br>
<br>
</div></div></blockquote></div><br>