| Message ID | 6e10c02cbb87fe30703de848455593df41ec7f4b.1333623555.git.jan.kiszka@siemens.com |
|---|---|
| State | New |
| Headers | show |
On Thu, 5 Apr 2012, Jan Kiszka wrote: > On 2012-04-05 14:56, Paolo Bonzini wrote: > > Il 05/04/2012 14:53, malc ha scritto: > >> On Thu, 5 Apr 2012, Paolo Bonzini wrote: > >> > >>> Il 05/04/2012 14:30, malc ha scritto: > >>>>>> 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). > >>> > >>> I was about to suggest the same, but how widespread is support for > >>> pthread_condattr_setclock? > >> > >> If it's not all is lost anyway. > > > > Only once every year. :) > > ...and not for the current user of this service which do not care that > much about the timeout and a potential delay or early shot. > An hour of potential delay mind you.
On 2012-04-05 15:20, malc wrote: > On Thu, 5 Apr 2012, Jan Kiszka wrote: > >> On 2012-04-05 15:00, malc wrote: >>> On Thu, 5 Apr 2012, Jan Kiszka wrote: >>> >>>> On 2012-04-05 14:56, Paolo Bonzini wrote: >>>>> Il 05/04/2012 14:53, malc ha scritto: >>>>>> On Thu, 5 Apr 2012, Paolo Bonzini wrote: >>>>>> >>>>>>> Il 05/04/2012 14:30, malc ha scritto: >>>>>>>>>> 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). >>>>>>> >>>>>>> I was about to suggest the same, but how widespread is support for >>>>>>> pthread_condattr_setclock? >>>>>> >>>>>> If it's not all is lost anyway. >>>>> >>>>> Only once every year. :) >>>> >>>> ...and not for the current user of this service which do not care that >>>> much about the timeout and a potential delay or early shot. >>>> >>> >>> An hour of potential delay mind you. >> >> Nope, look at posix-aio-compat. It's an optimization to keep the number >> worker threads under control. > > The code attempts to sleep for ten seconds, which can turn into an hour > and ten seconds if the conditions are right. Yes, but look at what happens then: it is unlikely that the thread will stay idle so long on a busy system (some request will wake it up earlier again), and even if that happens, the thread will simply consume a few resources "a bit" longer. Jan
diff --git a/qemu-thread-posix.c b/qemu-thread-posix.c index 9e1b5fb..cd65df2 100644 --- a/qemu-thread-posix.c +++ b/qemu-thread-posix.c @@ -17,6 +17,7 @@ #include <signal.h> #include <stdint.h> #include <string.h> +#include <sys/time.h> #include "qemu-thread.h" static void error_exit(int err, const char *msg) @@ -115,6 +116,28 @@ void qemu_cond_wait(QemuCond *cond, QemuMutex *mutex) error_exit(err, __func__); } +/* 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); + if (err && err != ETIMEDOUT) { + error_exit(err, __func__); + } + return err == 0; +} + void qemu_thread_create(QemuThread *thread, void *(*start_routine)(void*), void *arg, int mode) diff --git a/qemu-thread-posix.h b/qemu-thread-posix.h index ee4618e..9f00524 100644 --- a/qemu-thread-posix.h +++ b/qemu-thread-posix.h @@ -1,5 +1,6 @@ #ifndef __QEMU_THREAD_POSIX_H #define __QEMU_THREAD_POSIX_H 1 +#include <stdbool.h> #include "pthread.h" struct QemuMutex { @@ -14,4 +15,8 @@ struct QemuThread { pthread_t thread; }; +/* only provided for posix so far */ +bool qemu_cond_timedwait(QemuCond *cond, QemuMutex *mutex, + unsigned int timeout_ms); + #endif
First user will be POSIX compat aio. Windows use cases aren't in sight, so this remains a POSIX-only service for now. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> --- qemu-thread-posix.c | 23 +++++++++++++++++++++++ qemu-thread-posix.h | 5 +++++ 2 files changed, 28 insertions(+), 0 deletions(-)