Hi Arnaud, The below link will provide you a good summary of the situation, what we can do and how.
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). gethrtime (high resolution time) seems to be the fallback here: http://nadeausoftware.com/articles/2012/04/c_c_tip_how_measure_elapsed_real_time_benchmarking Yes, I’ve found that myself, too. HP-UX is definitely kind of a troublemaker... :-) CLOCK_MONOTONIC_PRECISE for BSD and CLOCK_HIGHRES for Solaris shall be used for monot. clock.. As already mentioned, mach_absolute_time shall be used for Mac OS X for the monotonic clock. For RTC on OS X, I’ve found the following (see answer #17): http://stackoverflow.com/questions/5167269/clock-gettime-alternative-in-mac-os-x For the HP-UX, I’llcheck whether gethrtime is available; if so, it’ll be used for monot. clock. If it’s not, well, I guess then HPUX user is screwed; I can’t find any other monot. clock implementation, so POSIX RTC shall have to be used. I’ll add the Windows-specific GetSystemTime* support, too, although for now, there’ll be no way to even compile the code :-( but this requires (for HPUX) the native compiler and CFLAGS set to "Extended Ansi" mode... so there is a 2nd (more general) fallback, using... gettimeofday! :-/ I can see no reason for using gettimeofday; we have POSIX clock (almost) everywhere, on OSX, we do have the above solution and on HPUX, we won’t do better than POSIX CLOCK_REALTIME with gettimeofday if we don’t have gethrtime... Another reading on configure checks: http://www.nco.ncep.noaa.gov/pmb/codes/nwprod/gempak/nawips2/extlibs/glib/v2.15.6/configure.in Thanks. As a separate comment, here is the list of remaining gettimeofday: common/common.c: gettimeofday(&now, NULL); drivers/bcmxcp_usb.c: gettimeofday(&start_time, NULL); drivers/bcmxcp_usb.c: gettimeofday(&now, NULL); drivers/dstate.c: gettimeofday(&now, NULL); drivers/main.c: gettimeofday(&timeout, NULL); drivers/usbhid-ups.c: gettimeofday(&now, NULL); Yep, I know what grep is for... ;-) But I use the –n switch, too. Thanks for the comments, tbc, Regards, vasek ________________________________ 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 ________________________________ -----Original Message----- > From: Charles Lepple [mailto:[email protected]<mailto:[email protected]>] > Sent: Monday, October 08, 2012 2:36 PM > To: Krpec, Vaclav > Cc: Arnaud Quette; Emilien KIA; > [email protected]<mailto:[email protected]> > List > Subject: Re: [Nut-upsdev] NUT Bugs #313634 & #313714: unification & > encapsulation of timer proposition > > [adding nut-upsdev back to CC list.] > > > While you at it --- I've written the nut_clock_gettime POSIX > > implementation so that fallback from monotonic POSIX clock impl. to > > RTC is actually also done if the system defines _POSIX_MONOTONIC_CLOCK > > macro, but the call ends with EINVAL (i.e. not implemented) if monotonic > > clock > is requested. > > I thought that may be a bit over-protective; as soon as the OS defines > > the detection macro, we should be entitled to expect it to work; > > EINVAL should therefore be considered an error and propagated. > > I'm confused. Could you post pseudocode, or the actual patch, for what is > being > described above? > > -- > Charles Lepple > clepple@gmail > >
_______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
