From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NRsl4-0001Ar-Cc for qemu-devel@nongnu.org; Mon, 04 Jan 2010 14:38:30 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NRsl0-00019x-F0 for qemu-devel@nongnu.org; Mon, 04 Jan 2010 14:38:30 -0500 Received: from [199.232.76.173] (port=35327 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NRsl0-00019u-A4 for qemu-devel@nongnu.org; Mon, 04 Jan 2010 14:38:26 -0500 Received: from mail2.shareable.org ([80.68.89.115]:47581) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NRsl0-0005sX-36 for qemu-devel@nongnu.org; Mon, 04 Jan 2010 14:38:26 -0500 Date: Mon, 4 Jan 2010 19:38:19 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 11/19] use a bottom half to run timers Message-ID: <20100104193819.GC13537@shareable.org> References: <1261382970-23251-1-git-send-email-pbonzini@redhat.com> <1261382970-23251-12-git-send-email-pbonzini@redhat.com> <4B424E95.4040806@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B424E95.4040806@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Paolo Bonzini , qemu-devel@nongnu.org Anthony Liguori wrote: > introduces a subtle semantic change. Previously, timers always ran > before bottom halves whereas after this change, timers may run after > some bottoms halves but before others. While this should be okay in > principle, in practice, I'm sure it'll introduce regressions. I'd be > very surprised if cris wasn't affected by this. In principle, if it does affect something, it seems likely there is already a buggy race condition. After all, if the timer and bottom half could trigger at the same time, which is the condition where the order is significant, then in principle the timer could have triggered slightly later because it depends on the host alarm behaviour. > But more importantly, I think timer dispatch needs to be part of the > select loop. malc has a git tree that replaces host alarm timers with > select() timeouts. This has a lot of really nice properties like it > eliminates the need for signals and EINTR handling. A move like this > would likely make this more difficult. I agree that select loop is better, but don't you still need a host alarm signal for when the guest is running for a long time without trapping? -- Jamie