From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33826) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZRen-0000gQ-Ng for qemu-devel@nongnu.org; Mon, 06 May 2013 16:05:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZRem-0000zs-61 for qemu-devel@nongnu.org; Mon, 06 May 2013 16:05:09 -0400 Received: from mail-ee0-f46.google.com ([74.125.83.46]:49464) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZRem-0000zQ-0L for qemu-devel@nongnu.org; Mon, 06 May 2013 16:05:08 -0400 Received: by mail-ee0-f46.google.com with SMTP id b57so1995762eek.33 for ; Mon, 06 May 2013 13:05:07 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51880CE9.1070602@redhat.com> Date: Mon, 06 May 2013 22:04:57 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1367597032-28934-1-git-send-email-mdroth@linux.vnet.ibm.com> <518761A6.4010209@redhat.com> <87obco2t3f.fsf@codemonkey.ws> <20130506183515.GC1685@vm> In-Reply-To: <20130506183515.GC1685@vm> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: mdroth Cc: Anthony Liguori , qemu-devel@nongnu.org, stefanha@redhat.com, qemulist@gmail.com Il 06/05/2013 20:35, mdroth ha scritto: > 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. I'm not sure it is that easy, but I agree entirely with everything else. > 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? Yes, very much. Paolo