Re: [Qemu-devel] [PATCH] qom: Make object_unref() free the object's memory when refcount goes to 0.

[Alexander Barabash <alexander_barabash@mentor.com>]

On 02/24/2012 05:11 PM, Anthony Liguori wrote:
> On 02/23/2012 10:21 AM, Alexander Barabash wrote:
>> On 02/22/2012 09:12 PM, Anthony Liguori wrote:
>>> On 02/22/2012 12:00 PM, alexander_barabash@mentor.com wrote:
>>>> From: Alexander Barabash<alexander_barabash@mentor.com>
>>>>
>> Why do you want to have a delete notifier list, rather than just a 
>> delete callback.
>
> Because a notifier list allows for third parties to receive the event 
> (think GObject signal/slots).
This is a valid point, but wouldn't it logical to issue an event before 
running the destructor?
Along the lines:

void object_finalize(void *data)
{
     Object *obj = data;
     TypeImpl *ti = obj->class->type;

     object_deinit(obj, ti);
     object_property_del_all(obj);

     g_assert(obj->ref == 0);

     object_finalized_notification(obj);
}

...

void object_unref(Object *obj)
{
     g_assert(obj->ref>  0);
     if (obj->ref == 1) {
         object_is_about_to_be_finalized_notification(obj);
     }
      obj->ref--;

     /* parent always holds a reference to its children */
     if (obj->ref == 0) {
         object_finalize(obj);
     }
}

Here, there is a notification while the object is still alive (in the 
sense that it has not been finalized).
Then, if the object is actually finalized, there is notification about that.

By the way, using weak references would spare us the notification list.
Object's memory will not be freed as long as a weak reference to it exists.
Access through a weak reference to a dead object will remove that weak 
reference.
This way, we shall also avoid problems with circular references between 
objects.

Regards,
Alex


>
>> At the point where refcount == 0, the destructor has been called 
>> already,
>> so there is not much to be done, except for reclaim the memory.
>
> Right, but the memory is not allocated by the core of Object.  This is 
> important in order to allow in-place object creation.  You could 
> special case this and have a flag to indicate whether the object has 
> allocated it's own memory or not but I think the two approaches end up 
> having equal complexity whereas the NotifierList gives you a lot more 
> flexibility.
>
> It makes it possible to use a small object allocator for Objects which 
> could be useful one day if we use objects in a fast path (like using 
> Objects to allocate packets in the network layer or requests in the 
> block layer).
>
> Regards,
>
> Anthony Liguori
>