From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37542) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZQKZ-00007s-Mc for qemu-devel@nongnu.org; Mon, 06 May 2013 14:40:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZQKY-00055p-AZ for qemu-devel@nongnu.org; Mon, 06 May 2013 14:40:11 -0400 Received: from mail-vc0-f178.google.com ([209.85.220.178]:63174) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZQKY-00055i-6Y for qemu-devel@nongnu.org; Mon, 06 May 2013 14:40:10 -0400 Received: by mail-vc0-f178.google.com with SMTP id kw10so3319446vcb.23 for ; Mon, 06 May 2013 11:40:09 -0700 (PDT) Sender: fluxion Date: Mon, 6 May 2013 13:35:15 -0500 From: mdroth Message-ID: <20130506183515.GC1685@vm> References: <1367597032-28934-1-git-send-email-mdroth@linux.vnet.ibm.com> <518761A6.4010209@redhat.com> <87obco2t3f.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87obco2t3f.fsf@codemonkey.ws> Subject: Re: [Qemu-devel] [RFC 0/9] QContext: QOM class to support multiple event loops List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Paolo Bonzini , qemu-devel@nongnu.org, stefanha@redhat.com, qemulist@gmail.com On Mon, May 06, 2013 at 07:25:24AM -0500, Anthony Liguori wrote: > Paolo Bonzini writes: > > > Il 03/05/2013 18:03, Michael Roth ha scritto: > >> These patches apply on top of qemu.git master, and can also be obtained from: > >> git://github.com/mdroth/qemu.git qcontext > >> > >> OVERVIEW > >> > >> This series introduces a set of QOM classes/interfaces for event > >> registration/handling: QContext and QSource, which are based closely on > >> their GMainContext/GSource GLib counterparts. > >> > >> QContexts can be created via the command-line via -object, and can also be > >> intructed (via -object params/properties) to automatically start a > >> thread/event-loop to handle QSources we attach to them. > > > > This is an awesome idea. > > Ack. > > > However, it seems a bit overengineered. > > Ack. > > > Why do we need QSource at all? > > In my opinion, we should first change dataplane to use AioContext as a > > GSource, and benchmark it thoroughly. If it is fast enough, we can > > "just" introduce a glib-based QContext and be done with it. Hopefully > > that is the case... > > Why even bother with QContext then? The QContext/GlibQContext object in general, or the QContext base class? In the case of the former, I think a wrapper around GLib that we can instantiate from the command-line line and query properties like TIDs from is necessary for robust control over event loops and CPU resources. We get this essentially for free with QOM, so I think it makes sense to use it. In the case of the latter I'm not too sure. Without the QSource abstraction there isn't much reason not to use the native GLib interfaces on the underlying GSources/GMainContexts directly. In which case GlibQContext would only need to be a container of sorts with some minor additions like spawning an event thread for itself. If we ever did need to switch it out in favor of a non-GLib implementation, it should be a mostly mechanical conversion of GSource->QSource and adding some wrappers around g_main_context_prepare/check/etc. Also along that line, if we're taking the approach of not adding infrastructure/cruft until we actually have a plan to use it, it probably makes sense to make QContext a concrete class implemented via GLib, and we can move the GLib stuff to a sub-class later if we ever end up with another QContext implementation. Does this seem reasonable? > > Regards, > > Anthony Liguori > > > > > Paolo >