qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: Re: [PATCH] Autodetect clock_gettime


From: François Revol
Subject: [Qemu-devel] Re: Re: [PATCH] Autodetect clock_gettime
Date: Tue, 15 Mar 2011 15:22:58 +0100

Le 15 mars 2011 à 14:58, Paolo Bonzini <address@hidden> a écrit :

>>>> Some POSIX OSes (such as Darwin) doesn't have clock_gettime.  This patch
>>>> falls back on gettimeofday if clock_gettime is not available.

Some code I've seen use #ifdef CLOCK_REALTIME but this doesn't seem right
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/time.h.html

>>> 
>>> This may be okay as a stopgap measure, but any sane porting target for QEMU 
>>> should have a monotonic clock.  In fact, Darwin has it.
>> 
>> Yes mach primitives could be used.  But why isn't a monotonic clock used on 
>> Linux ?  


cf. 
http://www.virtualbox.org/browser/trunk/src/VBox/Runtime/r3/darwin/time-darwin.cpp

You might want to check this as well :
http://www.wand.net.nz/~smr26/wordpress/2009/01/19/monotonic-time-in-mac-os-x/

>> According to man, CLOCK_MONOTONIC is monotonic
>> while CLOCK_REALTIME isn't.

Yes that's the reason both exist actually...

> Unfortunately, pthread timed wait/lock functions are documented to use the 
> realtime clock by default.  Using pthread_condattr_setclock is probably not 
> portable enough, and anyway there is no such function for mutexes so we're 
> stuck with CLOCK_REALTIME.  What you're patching is fine, but those functions 
> might actually go away soon as they're not supported on Win32.

If you're talking about qemu_mutex_timedlock and qemu_cond_timedwait, I failed 
to grep them anywhere else than at their own definition.

> So, in addition to what you've done, you should probably use those Mach 
> primitives in qemu-timer.h.

Likely.
(though I'd like to get QEMU to just work again here first as I need it running 
for friday...)

François.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]