From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37544) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFmgc-00025J-Nt for qemu-devel@nongnu.org; Thu, 05 Apr 2012 09:25:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFmgW-0004qT-6N for qemu-devel@nongnu.org; Thu, 05 Apr 2012 09:25:14 -0400 Received: from goliath.siemens.de ([192.35.17.28]:16336) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFmgV-0004m3-Sm for qemu-devel@nongnu.org; Thu, 05 Apr 2012 09:25:08 -0400 Message-ID: <4F7D9D2B.905@siemens.com> Date: Thu, 05 Apr 2012 15:24:59 +0200 From: Jan Kiszka MIME-Version: 1.0 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: malc Cc: Kevin Wolf , Paolo Bonzini , Anthony Liguori , "qemu-devel@nongnu.org" , Peter Maydell 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