From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34330) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yv5EN-0006oR-Js for qemu-devel@nongnu.org; Wed, 20 May 2015 10:44:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yv5EM-000552-0A for qemu-devel@nongnu.org; Wed, 20 May 2015 10:44:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59124) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yv5EL-00054x-Rd for qemu-devel@nongnu.org; Wed, 20 May 2015 10:44:21 -0400 Date: Wed, 20 May 2015 11:44:19 -0300 From: Eduardo Habkost Message-ID: <20150520144419.GE28075@thinpad.lan.raisama.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <555B6099.4060803@redhat.com> 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: Paolo Bonzini Cc: Andreas =?iso-8859-1?Q?F=E4rber?= , qemu-devel@nongnu.org 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) == NULL) { > return NULL; > } > dev = DEVICE(object_new(type)); > if (!dev) { > return NULL; > } > > if (!bus) { > bus = 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_child > (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 happen > after the caller would have called object_unref itself. But the caller won't ever call object_unref() because it doesn't own any reference, right? In this case, can we clarify the rules about how long 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? -- Eduardo