Re: [Qemu-devel] [PATCH 06/22] char: add a /chardevs container

[Marc-André Lureau]

Hi

On Fri, Feb 10, 2017 at 4:26 PM Paolo Bonzini <address@hidden> wrote:

>
> >
> > But if you unparent with the last ref, you remove the burden of knowing
> > if the object has been parented from the user. I don't see why that
> > would conflict with object_unparent(), you could still unparent(), and
> > keep the object referenced somewhere else.
>
> Isn't that exactly why you want them to be different?  unparent can do
> much more than unref, for example in the case of a device it will also
> unrealize it and destroy all buses underneath it.  Because the device
>

Shouldn't the last unref also unrealize/destroy everything?


> and bus have a circular reference, you cannot trigger the magic unparent
> behavior just by unref'ing the device.
>

Whoo, we have circular references on purposes? Is this lifecycle documented
somewhere? I wonder the rationale behind it.


>
> There are just two cases:
>
> - destruction immediately after creation, e.g. on error: new/unref
>
> - successful creation: new/add_child/unref, unparent when deleting
>

> and it's simpler to remember these two than to add magic behavior.
>
>
That doesn't change the problem, the user may not know if the object is
parented. So you have to pass this information along.



> > The two are not incompatible
> > to me. Afaik, most widget/hierarchy API work like that, the last unref
> > will implicitely unparent.
>
> LibreOffice's has some similarity with QOM, search for "dispose" at
> https://people.gnome.org/~michael/blog/2015-08-05-under-the-hood-5-0.html
>
> I don't see much parallel with the discussion here except that they had a
complicated model and tried to simplify it. That's what I also try to do.
-- 
Marc-André Lureau