On Mon, 19.10.09 12:45, Daniel Mack (daniel at caiaq.de) wrote: > > And clock_gettime we don't really need either. We need some kind of > > accurate system timers (preferably monotonic), and on Linux we use > > clock_gettime() for that. But we already have a fallback there for > > gettimeofday(). > > > > Or in other words, the current APIs pa_rtclock_get(), > > pa_rtclock_hrtimer() is supposed to be the abstract API that has > > different backends on different systems. I'd very much prefer if any > > MacOS specific code would simply be plugged in there instead of > > creating various new abstraction interfaces! > > Ok - what about the version below? I don't particularily like the > #ifdeffery jungle, but it is a lot less code now. Thanks. Looks much better. I reordered things a little now and merged this. Please verify that I didn't break the MacOS code while I did that! One thing though: ideally pa_rtclock_get() should return monotonic time, i.e. time that is independant from NTP, from timezone changes, from the user manipulating the system time. This is what on Linux is used if CLOCK_MONOTONIC is available. Only if it is not available we fall back to the unreliable wallclock time, i.e. CLOCK_REALTIME. Now, if I read http://developer.apple.com/mac/library/documentation/Darwin/Conceptual/KernelProgramming/services/services.html I see a microuptime() call referenced there and I wonder if this wouldn't be mre suitable for our needs? The epoch of CLOCK_MONOTONIC is not defined, but usually system bootup, so this would match more closely, and uptime should be strictly monotonic, too. Thanks for your work, Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
