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. > > Granted, time adjustments can make qemu_cond_timedwait in this primitive > (but easily portable) form less useful for other purposes. > > Jan > > -- mailto:av1...@comtv.ru
