From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39292) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V849d-0004JT-A9 for qemu-devel@nongnu.org; Sat, 10 Aug 2013 04:04:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V849U-0001QR-Nh for qemu-devel@nongnu.org; Sat, 10 Aug 2013 04:04:05 -0400 Received: from mail-ea0-x234.google.com ([2a00:1450:4013:c01::234]:41774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V849U-0001QF-Gs for qemu-devel@nongnu.org; Sat, 10 Aug 2013 04:03:56 -0400 Received: by mail-ea0-f180.google.com with SMTP id h10so2497475eaj.11 for ; Sat, 10 Aug 2013 01:03:55 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5205F3CA.1060009@redhat.com> Date: Sat, 10 Aug 2013 10:03:22 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <5205B251.2060907@linux.vnet.ibm.com> In-Reply-To: <5205B251.2060907@linux.vnet.ibm.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Convert AioContext to Gsource sub classes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wenchao Xia Cc: Kevin Wolf , Anthony Liguori , Ping Fan Liu , Stefan Hajnoczi , Michael Roth , qemu-devel Il 10/08/2013 05:24, Wenchao Xia ha scritto: > Hi folks, > I'd like form a series which remove AioContext's concept and > bind to glib's main loop more closely. Since changed place will be > a bit much so want to know your opinion before real coding: I'm not sure I understand... What does it buy you to split AioContext this way? First, BhSource and FdSource are needed by block drivers, and BhSource needs the notifier to interrupt the main loop. Second, AioContext is _already_ a GSource exactly to integrate closely with GLib's main loop. Look at the series that introduced AioContext back in October 2012. The main AioContext is already added as a GSource to the iothread's main loop; aio_wait is used in dataplane for simplicity, but it could also use a separate GMainLoop and add AioContext there as a GSource. Paolo > changes: > **before patch: > typedef struct AioContext { > GSource source; > int walking_handlers; > QemuMutex bh_lock; > struct QEMUBH *first_bh; > int walking_bh; > EventNotifier notifier; > GArray *pollfds; > struct ThreadPool *thread_pool; > } AioContext; > > **After patch: > typedef struct BhSource { > GSource source; > QemuMutex bh_lock; > struct QEMUBH *first_bh; > int walking_bh; > } BhSource; > > typedef struct FdSource { > GSource source; > int walking_handlers; > EventNotifier notifier; > GArray *pollfds; > struct ThreadPool *thread_pool; > } FdSource; > > Benefits: > Original code have a mix of Gsource and GMainContext's concept, we > may want to add wrapper functions around GMainContext's functions, such > as g_main_context_acquire(), g_main_context_prepare(), which brings > extra effort if you want to form a good and clear API layer. With > this changes, all qemu's custom code is attached under Gsource, we > have a clear GMainContext's API layer for event loop, no wrapper is > needed, and the event's loop API is glib's API, a clear layer let > me form a library or adding more things. > > before: > qemu's mainloop caller, BH user, fd user > | > AioContext > | > GMainContext > > > after: > qemu's mainloop caller > | BH user fd user > GmainContext | | > |--------------------------------|--BhSource | > |-------------FdSource > > > Note: > FdSource could be split more into ThreadSource and FdSource, which > distinguish more. It can be done easily if the change of this series > is online, when found necessary. > > More reasons: > When I thinking how to bind library code to a thread context, it may > need to add Context's concept into API of block.c. If I use AioContext, > there will need a wrapper API to run the event loop. But If I got > glib's GmainContext, things become simple.