From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50346) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFmsk-0007If-1R for qemu-devel@nongnu.org; Thu, 05 Apr 2012 09:37:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFmsZ-00088f-2a for qemu-devel@nongnu.org; Thu, 05 Apr 2012 09:37:44 -0400 Received: from fe01x03-cgp.akado.ru ([77.232.31.164]:50454 helo=akado.ru) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFmsY-00085Z-RD for qemu-devel@nongnu.org; Thu, 05 Apr 2012 09:37:34 -0400 Date: Thu, 5 Apr 2012 17:37:12 +0400 (MSK) From: malc In-Reply-To: <4F7D9D2B.905@siemens.com> Message-ID: References: <6e10c02cbb87fe30703de848455593df41ec7f4b.1333623555.git.jan.kiszka@siemens.com> <4F7D887B.1030104@siemens.com> <4F7D921E.9040003@redhat.com> <4F7D9691.9090507@redhat.com> <4F7D9735.7040509@siemens.com> <4F7D980B.2040002@siemens.com> <4F7D9D2B.905@siemens.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [Qemu-devel] [PATCH v3 01/10] Introduce qemu_cond_timedwait for POSIX List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Kevin Wolf , Paolo Bonzini , Anthony Liguori , "qemu-devel@nongnu.org" , Peter Maydell 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:av1474@comtv.ru