[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 5/8] qom: add object_new_with_props / object_

From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH v4 5/8] qom: add object_new_with_props / object_new_withpropv constructors
Date: Wed, 20 May 2015 11:44:19 -0300
User-agent: Mutt/1.5.23 (2014-03-12)

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]