From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51149) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFmcZ-0008Vw-EI for qemu-devel@nongnu.org; Thu, 05 Apr 2012 09:21:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFmcM-0003Uo-Kc for qemu-devel@nongnu.org; Thu, 05 Apr 2012 09:21:02 -0400 Received: from fe01x03-cgp.akado.ru ([77.232.31.164]:58576 helo=akado.ru) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFmcM-0003U4-Cr for qemu-devel@nongnu.org; Thu, 05 Apr 2012 09:20:50 -0400 Date: Thu, 5 Apr 2012 17:20:34 +0400 (MSK) From: malc In-Reply-To: <4F7D980B.2040002@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> 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: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:av1474@comtv.ru