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
