From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34919) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG8z1-0008Ej-Pj for qemu-devel@nongnu.org; Thu, 14 Mar 2013 10:18:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UG8yu-00021w-4p for qemu-devel@nongnu.org; Thu, 14 Mar 2013 10:18:15 -0400 Received: from mail-bk0-x236.google.com ([2a00:1450:4008:c01::236]:51501) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG8yt-00021q-Tp for qemu-devel@nongnu.org; Thu, 14 Mar 2013 10:18:08 -0400 Received: by mail-bk0-f54.google.com with SMTP id w5so1053907bku.27 for ; Thu, 14 Mar 2013 07:18:06 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5141DC1A.6020402@redhat.com> Date: Thu, 14 Mar 2013 15:18:02 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1363154346-14827-1-git-send-email-qemulist@gmail.com> <51405BEA.6080109@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 0/2] port network layer onto glib List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: liu ping fan Cc: Stefan Hajnoczi , "Michael S. Tsirkin" , mdroth , Anthony Liguori , qemu-devel@nongnu.org Il 14/03/2013 15:08, liu ping fan ha scritto: > On Wed, Mar 13, 2013 at 6:58 PM, Paolo Bonzini wrote: >> Il 13/03/2013 06:59, Liu Ping Fan ha scritto: >>> These series aim to port network backend onto glib, and >>> prepare for moving towards making network layer mutlit-thread. >>> The brief of the whole aim and plan is documented on >>> http://wiki.qemu.org/Features/network_reentrant >>> >>> In these series, attach each NetClientState with a GSource >>> At the first, I use AioContext instead of GSource, but after discussion, >>> I think with GSource, we can integrated with glib more closely. >> >> Integrating with glib by itself is pointless. What is the *benefit*? >> >> We have a pretty good idea of how to make multithreaded device models >> using AioContext, since we are using it for the block layer and >> virtio-blk dataplane. Doing the same work twice, on two different >> frameworks, doesn't seem like a very good idea. >> > One thing is that AioContext lacks of something which can handle > IOCanReadHandler. See reply to Anthony. io_flush is very similar to that. Right now it affects both reading and writing, but I think it wouldn't be a problem to make it affect io_read only. Paolo