From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:56368)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <p.fedin@samsung.com>) id 1ZjjXv-0005ju-A9
	for qemu-devel@nongnu.org; Wed, 07 Oct 2015 03:53:56 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <p.fedin@samsung.com>) id 1ZjjXr-0006wo-1z
	for qemu-devel@nongnu.org; Wed, 07 Oct 2015 03:53:55 -0400
Received: from mailout4.w1.samsung.com ([210.118.77.14]:49141)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <p.fedin@samsung.com>) id 1ZjjXq-0006wC-LQ
	for qemu-devel@nongnu.org; Wed, 07 Oct 2015 03:53:50 -0400
Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245])
	by mailout4.w1.samsung.com
	(Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5
	2014)) with ESMTP id <0NVU00MSJB9NON10@mailout4.w1.samsung.com> for
	qemu-devel@nongnu.org; Wed, 07 Oct 2015 08:53:47 +0100 (BST)
From: Pavel Fedin <p.fedin@samsung.com>
References: <016801d10034$6356fe40$2a04fac0$@samsung.com>
	<20151006235504.GP3861@voom.fritz.box>
In-reply-to: <20151006235504.GP3861@voom.fritz.box>
Date: Wed, 07 Oct 2015 10:53:46 +0300
Message-id: <014a01d100d5$4bfe8320$e3fb8960$@samsung.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Content-language: ru
Subject: Re: [Qemu-devel] [PATCH] qobject: Replace property list with
	GHashTable
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: 'David Gibson' <david@gibson.dropbear.id.au>
Cc: 'Paolo Bonzini' <pbonzini@redhat.com>, qemu-devel@nongnu.org

 Hello!

> Hmm.. modifying a child object internally should be fine, shouldn't
> it?  IIUC only trying to remove it, change the key or the pointer to
> the value should be problematic.

 The glib documentation says that "Modifying the hash table after calling this function invalidates
the returned iterator". glib even includes an optional checks for this (under #ifndef
G_DISABLE_ASSERT): https://github.com/GNOME/glib/blob/master/glib/ghash.c#L782
 But, if you look, for example, inside  g_hash_table_iter_remove(), you'll see that they do exactly
the same (just remove the element), and then work around own check by incrementing both versions.

> How much extra memory does each Object take with no (or few) properties by
> using a hash table rather than a simple list here?

 I believe not a lot. GHashTable consists of 7 interers + 7 pointers:
https://github.com/GNOME/glib/blob/master/glib/ghash.c#L212
	
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia