[pulseaudio-discuss] [PATCH 4/4] Wrap clock_gettime and friends

Lennart Poettering lennart at poettering.net
Fri Oct 30 17:41:19 PDT 2009


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



More information about the pulseaudio-discuss mailing list