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 -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
