From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33472 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PhgL4-00087V-KD for qemu-devel@nongnu.org; Tue, 25 Jan 2011 05:41:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PhgL3-0004fq-Ez for qemu-devel@nongnu.org; Tue, 25 Jan 2011 05:41:30 -0500 Received: from mail-bw0-f45.google.com ([209.85.214.45]:53247) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PhgL3-0004fk-5A for qemu-devel@nongnu.org; Tue, 25 Jan 2011 05:41:29 -0500 Received: by bwz16 with SMTP id 16so193621bwz.4 for ; Tue, 25 Jan 2011 02:41:27 -0800 (PST) Sender: Paolo Bonzini Message-ID: <4D3EA8D3.1030807@redhat.com> Date: Tue, 25 Jan 2011 11:41:23 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1295902845-29807-1-git-send-email-aliguori@us.ibm.com> <4D3DEEE1.90904@redhat.com> <4D3DF6C0.9040809@codemonkey.ws> In-Reply-To: <4D3DF6C0.9040809@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC 0/7] Introduce hard dependency on glib List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Arun Bharadwaj , Marcelo Tosatti , Paul Brook , Stefan Hajnoczi , qemu-devel@nongnu.org On 01/24/2011 11:01 PM, Anthony Liguori wrote: >>> - JSON parser >> >> I think our JSON parser is much better than JsonGlib (which isn't >> anyway a part of GLib proper). > > Not sure how much either of these matter, but we should at least drop > QObject and convert our JSON parser to use GValues such that we can > treat the JSON parser as a stand alone component. Not too nice actually, as GHashTable and GArrays are not GValues. > I've been thinking about this myself. I think slirp is probably best > handled as a GSource as much as I don't want to do it. I don't see > another option. Yes. Track the previous bitmap of fd's and add/remove pollfd's when they appear into (resp. disappear from) the bitmap. Note that the glib main loop can be quadratic in the number of file descriptors BTW. > We can't use the g_timeout_source directly because the interval is > milliseconds. Our deadlines are rounded to milliseconds anyway. However, with an iothread you really do not need signals anymore. The dynticks code maps pretty well to a GSource. > Obviously, implementing a GSource is the > best long term approach but I think there's a reasonable short term one. Or yet another unfinished transition. Paolo "let's do it in Vala then"