On Thu, 5 Apr 2012, Jan Kiszka wrote:
> 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
^^^^ This is what i have issues with...
> >> 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.
not the practicallity...
--
mailto:av1...@comtv.ru
