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

Lennart Poettering lennart at poettering.net
Tue Nov 3 14:33:37 PST 2009


On Sun, 01.11.09 20:16, Daniel Mack (daniel at caiaq.de) wrote:

> 
> On Sat, Oct 31, 2009 at 01:41:19AM +0100, Lennart Poettering wrote:
> > 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!
> 
> My build bails due to an undefined 'CLOCK_REALTIME', and this is because
> HAVE_CLOCK_GETTIME is also defined on Darwin.

Uh?

If HAVE_CLOCK_GETTIME is set, than this means that clock_gettime() is
available, too. So why are we emulating it then?

I don't follow...

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