From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:40479)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <p.fedin@samsung.com>) id 1ZyDz1-0003cX-Ag
	for qemu-devel@nongnu.org; Mon, 16 Nov 2015 02:13:48 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <p.fedin@samsung.com>) id 1ZyDyy-0005Sk-56
	for qemu-devel@nongnu.org; Mon, 16 Nov 2015 02:13:47 -0500
Received: from mailout4.w1.samsung.com ([210.118.77.14]:47924)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <p.fedin@samsung.com>) id 1ZyDyx-0005Sb-V1
	for qemu-devel@nongnu.org; Mon, 16 Nov 2015 02:13:44 -0500
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 <0NXW00F6EC2SDV70@mailout4.w1.samsung.com> for
	qemu-devel@nongnu.org; Mon, 16 Nov 2015 07:13:40 +0000 (GMT)
From: Pavel Fedin <p.fedin@samsung.com>
References: <1444739866-14798-1-git-send-email-berrange@redhat.com>
	<1444739866-14798-7-git-send-email-berrange@redhat.com>
	<5646286B.2030307@suse.de> <56464F8A.3070709@de.ibm.com>
	<56465533.3030501@suse.de>
In-reply-to: <56465533.3030501@suse.de>
Date: Mon, 16 Nov 2015 10:13:38 +0300
Message-id: <008001d1203e$51838510$f48a8f30$@samsung.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7bit
Content-language: ru
Subject: Re: [Qemu-devel] [PATCH v4 6/7] qom: replace object 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: =?ISO-8859-1?Q?'Andreas_F=E4rber'?= <afaerber@suse.de>, 'Christian Borntraeger' <borntraeger@de.ibm.com>
Cc: 'Peter Maydell' <peter.maydell@linaro.org>, 'Paolo Bonzini' <pbonzini@redhat.com>, qemu-devel@nongnu.org, 'Markus Armbruster' <armbru@redhat.com>

 Hello!

> >> (process:4102): GLib-CRITICAL **: g_hash_table_iter_next: assertion
> >> 'ri->version == ri->hash_table->version' failed
> >>
> >> (process:4102): GLib-CRITICAL **: g_hash_table_iter_next: assertion
> >> 'ri->version == ri->hash_table->version' failed
> >>
> >> (process:4102): GLib-CRITICAL **: iter_remove_or_steal: assertion
> >> 'ri->version == ri->hash_table->version' failed

 Wow... Actually this may come from attempts to modify the tree inside iteration.

> Thanks! sclp_init() seems to violate several QOM design principles in
> that it uses object_new() during TypeInfo::instance_init() and uses a
> TYPE_... constant as property name. But nothing else stands out immediately.

 I think we should refactor this and retry. If not all problems go away, then we are indeed modifying the tree during iteration, and
we have to find some solution.
 I wonder... Could we have both list and hashtable? hashtable for searching by name and list for iteration. In this case we would
not have to use glib's iterators, and would be free of problems with them. Just keep the list and hashtable in sync.
 Or, is there any hashtable implementation out there which would keep iterators valid during modification?
 OTOH, glib has a function "remove the element at iterator's position", and we could postpone addition. So, perhaps, using both
containers would be an overkill, just refactor the code to adapt to the new behavior.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia