qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 01/10] Introduce qemu_cond_timedwait for POSI


From: malc
Subject: Re: [Qemu-devel] [PATCH v3 01/10] Introduce qemu_cond_timedwait for POSIX
Date: Thu, 5 Apr 2012 16:30:14 +0400 (MSK)
User-agent: Alpine 2.00 (LNX 1167 2008-08-23)

On Thu, 5 Apr 2012, Jan Kiszka wrote:

> On 2012-04-05 13:19, Peter Maydell wrote:
> > On 5 April 2012 11:59, Jan Kiszka <address@hidden> wrote:
> >> +/* Returns true if condition was signals, false if timed out. */
> >> +bool qemu_cond_timedwait(QemuCond *cond, QemuMutex *mutex,
> >> +                         unsigned int timeout_ms)
> >> +{
> >> +    struct timespec ts;
> >> +    struct timeval tv;
> >> +    int err;
> >> +
> >> +    gettimeofday(&tv, NULL);
> >> +    ts.tv_sec = tv.tv_sec + timeout_ms / 1000;
> >> +    ts.tv_nsec = tv.tv_usec * 1000 + timeout_ms % 1000;
> >> +    if (ts.tv_nsec > 1000000000) {
> >> +        ts.tv_sec++;
> >> +        ts.tv_nsec -= 1000000000;
> >> +    }
> >> +    err = pthread_cond_timedwait(&cond->cond, &mutex->lock, &ts);
> > 
> > Use clock_gettime() and avoid the need to convert a struct timeval
> > to a struct timespec ?
> 
> Would save that "* 1000". I just wondered why we do not use it elsewhere
> in QEMU and was reluctant to risk some BSD breakage.
> 

It's probably worth mentioning that using anything other than 
clock_gettime and CLOCK_MONOTONING (as well as setting proper pthread
clock attr on the condition variable) is prone to the surprises (such
as NTP corrections and daylight saving changes).

-- 
mailto:address@hidden



reply via email to

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