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. Granted, time adjustments can make qemu_cond_timedwait in this primitive (but easily portable) form less useful for other purposes. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
