From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59839) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGlEK-0002KT-SM for qemu-devel@nongnu.org; Wed, 26 Sep 2012 02:36:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGlEJ-0003yr-DT for qemu-devel@nongnu.org; Wed, 26 Sep 2012 02:36:20 -0400 Received: from mail-wg0-f41.google.com ([74.125.82.41]:56848) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGlEJ-0003yJ-7D for qemu-devel@nongnu.org; Wed, 26 Sep 2012 02:36:19 -0400 Received: by wgbds1 with SMTP id ds1so3809102wgb.4 for ; Tue, 25 Sep 2012 23:36:18 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5062A260.6020708@redhat.com> Date: Wed, 26 Sep 2012 08:36:16 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1348577763-12920-1-git-send-email-pbonzini@redhat.com> <1348577763-12920-10-git-send-email-pbonzini@redhat.com> <87r4ppn4nk.fsf@codemonkey.ws> In-Reply-To: <87r4ppn4nk.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 09/17] aio: prepare for introducing GSource-based dispatch List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org Il 26/09/2012 00:01, Anthony Liguori ha scritto: >> > + node->pfd.events = G_IO_ERR; >> > + node->pfd.events |= (io_read ? G_IO_IN | G_IO_HUP : 0); >> > + node->pfd.events |= (io_write ? G_IO_OUT : 0); >> > } > Should we even set G_IO_ERR? I think that corresponds to exceptfd No, that would be G_IO_PRI. > in select() but we've never set that historically. I know glib recommends > it but I don't think it's applicable to how we use it. > > Moreover, the way you do dispatch, if G_IO_ERR did occur, we'd dispatch > both the read and write handlers which definitely isn't right. I'm not sure what gives POLLERR. Probably a connect() that fails, and in that case dispatching on the write handler would be okay. But I was not sure and calling both is safe: handlers have to be ready for spurious wakeups anyway, it happens if qemu_aio_wait dispatches from a VCPU thread before the main loop gets hold of the big lock. > I think it's easiest just to drop it. That's indeed the case, since the current code never sets either G_IO_HUP or G_IO_ERR. Paolo