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
On Tue, Oct 06, 2015 at 03:02:17PM +0200, Laszlo Ersek wrote:
> David,
>
> On 10/06/15 14:41, Pavel Fedin wrote:
> > ARM GICv3 systems with large number of CPUs create lots of IRQ pins. Since
> > every pin is represented as a property, number of these properties becomes
> > very large. Every
On Tue, Oct 06, 2015 at 03:41:56PM +0300, Pavel Fedin wrote:
> ARM GICv3 systems with large number of CPUs create lots of IRQ pins. Since
> every pin is represented as a property, number of these properties becomes
> very large. Every property add first makes sure there's no duplicates.
>
David,
On 10/06/15 14:41, Pavel Fedin wrote:
> ARM GICv3 systems with large number of CPUs create lots of IRQ pins. Since
> every pin is represented as a property, number of these properties becomes
> very large. Every property add first makes sure there's no duplicates.
> Traversing the list
On 06/10/2015 15:02, Laszlo Ersek wrote:
>> void object_unparent(Object *obj)
>> {
>> if (obj->parent) {
>> -object_property_del_child(obj->parent, obj, NULL);
>> +g_hash_table_foreach_remove(obj->properties,
This should be obj->parent->properties.
Otherwise, the patch
ARM GICv3 systems with large number of CPUs create lots of IRQ pins. Since
every pin is represented as a property, number of these properties becomes
very large. Every property add first makes sure there's no duplicates.
Traversing the list becomes very slow, therefore qemu initialization takes
Hello!
> Shouldn't this help similarly with the problem that 94649d423e worked
> around? (Although that patch has standalone merits of course.)
Yes, and also 6c76b37742d4db8176af37b667b5420727e79e2c.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
