From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51389) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yv5yk-0004Ah-Cb for qemu-devel@nongnu.org; Wed, 20 May 2015 11:32:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yv5yf-0001hG-Rh for qemu-devel@nongnu.org; Wed, 20 May 2015 11:32:18 -0400 Received: from cantor2.suse.de ([195.135.220.15]:57009 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yv5yf-0001fa-IR for qemu-devel@nongnu.org; Wed, 20 May 2015 11:32:13 -0400 Message-ID: <555CA8FB.9050608@suse.de> Date: Wed, 20 May 2015 17:32:11 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1431533649-23115-1-git-send-email-berrange@redhat.com> <1431533649-23115-6-git-send-email-berrange@redhat.com> <555B5C2E.5050903@suse.de> <20150519155528.GF8535@redhat.com> <555B6099.4060803@redhat.com> <20150520144419.GE28075@thinpad.lan.raisama.net> <20150520151803.GA23989@redhat.com> In-Reply-To: <20150520151803.GA23989@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v4 5/8] qom: add object_new_with_props / object_new_withpropv constructors List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , Eduardo Habkost Cc: Paolo Bonzini , qemu-devel@nongnu.org Am 20.05.2015 um 17:18 schrieb Daniel P. Berrange: > On Wed, May 20, 2015 at 11:44:19AM -0300, Eduardo Habkost wrote: >> On Tue, May 19, 2015 at 06:11:05PM +0200, Paolo Bonzini wrote: >>> On 19/05/2015 17:55, Daniel P. Berrange wrote: >>>> Paolo told me on previous posting that object_property_add_child() >>>> holds a reference on 'obj' for as long as it is registered in the >>>> object hierarchy composition. So it sufficient to rely on that long >>>> term reference, and let the caller dispose of the object by calling >>>> object_unparent(obj) when finally done. >>> >>> For an example of the same pattern: >>> >>> DeviceState *qdev_try_create(BusState *bus, const char *type) >>> { >>> DeviceState *dev; >>> >>> if (object_class_by_name(type) =3D=3D NULL) { >>> return NULL; >>> } >>> dev =3D DEVICE(object_new(type)); >>> if (!dev) { >>> return NULL; >>> } >>> >>> if (!bus) { >>> bus =3D sysbus_get_default(); >>> } >>> >>> qdev_set_parent_bus(dev, bus); >>> object_unref(OBJECT(dev)); >>> return dev; >>> } >>> >>> Effectively this is idea as GObject's "floating reference". >>> qdev_set_parent_bus (in qdev_try_create) and object_property_add_chil= d >>> (in Daniel's patches) "sink" the floating reference by doing >>> object_unref. If we had floating references, the object would be >>> returned to the caller unref'ed anyway. >> >> I was agreeing with Andreas at first (because it would make the >> reference ownership rules simpler and easier to understand), until I >> noticed that every call of qdev_try_create() and object_resolve_path() >> in the code would need an additional object_unref() call if we didn't >> use this pattern. >> >> But it bothers me that this exceptional behavior is not documented on >> neither qdev_try_create() or object_resolve_path(). >> >>> >>> Of course, the reference can go away via QMP. But that will only hap= pen >>> after the caller would have called object_unref itself. >> >> But the caller won't ever call object_unref() because it doesn't own a= ny >> reference, right? In this case, can we clarify the rules about how lon= g >> can callers safely expect the object to stay around? Can the object be >> disposed in another thread? Can it be disposed only when some specific >> events happen? >=20 > In the inline docs for object_new_with_props I wrote >=20 > * The returned object will have one stable reference maintained > * for as long as it is present in the object hierarchy. >=20 > We could expand it to explicitly say that 'object_unparent' is required > to remove the object from the hierarchy and free it. I've already queued this series - let's hold off changes for a bit. :) Regards, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Felix Imend=C3=B6rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; = HRB 21284 (AG N=C3=BCrnberg)