|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] [patch 1/7] qemu: mutex/thread/cond wrappers |
Date: | Tue, 24 Mar 2009 09:43:16 +0200 |
User-agent: | Thunderbird 2.0.0.21 (X11/20090320) |
Marcelo Tosatti wrote:
and why milliseconds?Well, its suitable for the current purposes. Any other suggestion?
uint64_t nanoseconds. It's standard timekeeping in qemu: #define QEMU_TIMER_BASE 1000000000LL and it's of course best to limit the number of standards.
Also, maybe uint64_t is a better type.I would have preferred a deadline instead of a timeout, but we'll see on the next patches.+ +int qemu_mutex_timedlock(QemuMutex *mutex, unsigned int msecs) +{ + struct timespec ts; + + clock_gettime(CLOCK_REALTIME, &ts); + add_to_timespec(&ts, msecs); + + return pthread_mutex_timedlock(&mutex->lock, &ts); +}Please expand?
Instead of 'sleep until n nanoseconds have elapsed', 'sleep until get_clock() >= deadline'. I think it simplifies things somewhat.
-- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
[Prev in Thread] | Current Thread | [Next in Thread] |