From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58136) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uz8XG-0004dB-Ra for qemu-devel@nongnu.org; Tue, 16 Jul 2013 12:55:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uz8XF-0005Ys-Oi for qemu-devel@nongnu.org; Tue, 16 Jul 2013 12:55:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55159) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uz8XF-0005Xg-Ht for qemu-devel@nongnu.org; Tue, 16 Jul 2013 12:55:33 -0400 Message-ID: <51E57AF3.1050409@redhat.com> Date: Tue, 16 Jul 2013 18:55:15 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1373127897-3445-1-git-send-email-alex@alex.org.uk> <51E4063D.6010308@redhat.com> <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> In-Reply-To: <19631228D7B62545DC6A2928@Ximines.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Alex Bligh Cc: Kevin Wolf , Anthony Liguori , qemu-devel@nongnu.org, Stefan Hajnoczi , rth@twiddle.net Il 16/07/2013 18:14, Alex Bligh ha scritto: > Paolo, > >>> 3. aio_poll calls aio_bh_poll. If this returns true, this indicates >>> at least one non-idle bh exists, which causes aio_poll not to >>> block. >> >> No, this indicates that at least one scheduled non-idle bh exist*ed*, >> which causes aio_poll not to block (because some progress has been done). > > Ah yes, in the sense the callback will have been called and it now > doesn't exist. Or at least isn't scheduled. >>> 4. aio_poll then calls g_poll (POSIX) or WaitForMultipleObjects >>> (Windows). However, the timeout is either 0 or infinite. >>> Both functions take a milliseconds (yuck) timeout, but that >>> is not used. >> >> I agree with the yuck. :) But Linux has the nanoseconds-resolution >> ppoll, too. > > Sadly I don't think we have a g_ppoll. Doesn't matter, poll==g_poll on POSIX systems. You can just use poll (or g_poll) on non-Linux, and ppoll on Linux. >> 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. Paolo