[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 01/10] Introduce qemu_cond_timedwait for POSI
From: |
malc |
Subject: |
Re: [Qemu-devel] [PATCH v3 01/10] Introduce qemu_cond_timedwait for POSIX |
Date: |
Thu, 5 Apr 2012 17:37:12 +0400 (MSK) |
User-agent: |
Alpine 2.00 (LNX 1167 2008-08-23) |
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:address@hidden
- Re: [Qemu-devel] [PATCH v3 01/10] Introduce qemu_cond_timedwait for POSIX, (continued)
- Re: [Qemu-devel] [PATCH v3 01/10] Introduce qemu_cond_timedwait for POSIX, Peter Maydell, 2012/04/05
- Re: [Qemu-devel] [PATCH v3 01/10] Introduce qemu_cond_timedwait for POSIX, malc, 2012/04/05
- Re: [Qemu-devel] [PATCH v3 01/10] Introduce qemu_cond_timedwait for POSIX, Paolo Bonzini, 2012/04/05
- Re: [Qemu-devel] [PATCH v3 01/10] Introduce qemu_cond_timedwait for POSIX, malc, 2012/04/05
- Re: [Qemu-devel] [PATCH v3 01/10] Introduce qemu_cond_timedwait for POSIX, Paolo Bonzini, 2012/04/05
- Re: [Qemu-devel] [PATCH v3 01/10] Introduce qemu_cond_timedwait for POSIX, Jan Kiszka, 2012/04/05
- Re: [Qemu-devel] [PATCH v3 01/10] Introduce qemu_cond_timedwait for POSIX, malc, 2012/04/05
- Re: [Qemu-devel] [PATCH v3 01/10] Introduce qemu_cond_timedwait for POSIX, Jan Kiszka, 2012/04/05
- Re: [Qemu-devel] [PATCH v3 01/10] Introduce qemu_cond_timedwait for POSIX, malc, 2012/04/05
- Re: [Qemu-devel] [PATCH v3 01/10] Introduce qemu_cond_timedwait for POSIX, Jan Kiszka, 2012/04/05
- Re: [Qemu-devel] [PATCH v3 01/10] Introduce qemu_cond_timedwait for POSIX,
malc <=
- Re: [Qemu-devel] [PATCH v3 01/10] Introduce qemu_cond_timedwait for POSIX, malc, 2012/04/05
[Qemu-devel] [PATCH v3 04/10] qemu-thread: Factor out qemu_error_exit, Jan Kiszka, 2012/04/05
[Qemu-devel] [PATCH v3 03/10] Switch compatfd to QEMU thread, Jan Kiszka, 2012/04/05
[Qemu-devel] [PATCH v3 05/10] Introduce QemuEvent abstraction, Jan Kiszka, 2012/04/05
[Qemu-devel] [PATCH v3 02/10] Switch POSIX compat AIO to QEMU abstractions, Jan Kiszka, 2012/04/05
[Qemu-devel] [PATCH v3 06/10] Use QemuEvent in main loop, Jan Kiszka, 2012/04/05
[Qemu-devel] [PATCH v3 07/10] Drop unused qemu_eventfd, Jan Kiszka, 2012/04/05
[Qemu-devel] [PATCH v3 10/10] Remove EventNotifier, Jan Kiszka, 2012/04/05