From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50312) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzMVV-0005SA-On for qemu-devel@nongnu.org; Wed, 17 Jul 2013 03:50:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UzMVU-0000Lt-FX for qemu-devel@nongnu.org; Wed, 17 Jul 2013 03:50:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54405) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzMVU-0000Lm-4T for qemu-devel@nongnu.org; Wed, 17 Jul 2013 03:50:40 -0400 Date: Wed, 17 Jul 2013 09:50:25 +0200 From: Kevin Wolf Message-ID: <20130717075025.GA2458@dhcp-200-207.str.redhat.com> References: <75638CBA408455BF52192DA7@Ximines.local> <51E4613D.9000106@redhat.com> <44590808AF4A6E7DC093637A@nimrod.local> <51E4E54A.10908@redhat.com> <51E4F77C.2090509@redhat.com> <794E19D97CCC267CCBFA8397@Ximines.local> <51E56A1A.50502@redhat.com> <19631228D7B62545DC6A2928@Ximines.local> <51E57AF3.1050409@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51E57AF3.1050409@redhat.com> Subject: Re: [Qemu-devel] [PATCH] [RFC] aio/async: Add timed bottom-halves List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Anthony Liguori , Stefan Hajnoczi , qemu-devel@nongnu.org, Alex Bligh , rth@twiddle.net Am 16.07.2013 um 18:55 hat Paolo Bonzini geschrieben: > >> But I wouldn't introduce a > >> new one-off concept (almost as much of a hack as idle BHs), I would > >> rather reuse as much code as possible from QEMUTimer/QEMUClock. I must > >> admit I don't have a clear idea of how the API would look like. > > > > So the reason I was trying to avoid using QEMUTimer stuff was that > > bh's get called from aio_poll and it was not evident that all timers > > would be safe to call from aio_poll. > > It wouldn't. > > > What do you think? In the end I thought the schedule_bh_at stuff > > was simpler. > > It is simpler, but I'm not sure it is the right API. Of course, if > Kevin and Stefan says it is, I have no problem with that. Well, the one thing I'm pretty sure we need is an additional interface, so that existing timers continue to run only from the main loop, and new timers / timed BHs / whatever have the option to run in nested event loops as well. I don't really care what the thing is called as long as it does what is needed. Timed BHs seemed to do that, so I agreed. Kevin