Re: Object Reference counting idea.

[Maciej Stachowiak <mjs eazel com>]

Miguel de Icaza <miguel helixcode com> writes:

> [Elliot, can you read the last paragraph?]
> 
> Dum de dum.
> 
>    So, Michael and I have been discussing for some time a feature that
> we want to add to the base BonoboObject (dont worry, there are no API
> changes for this, it is entirely an optimizaton).  We would like the
> default ::ref and ::unref method implementations to keep track of
> reference counts in a per-client fashion instead of having an
> object-global reference count.
> 
>    This approach would solve a number of problems:
> 
> 	1. Clients with ref leaks: causing objects to never be destroyed.
> 
> 	2. Client with too many unrefs: causing other clients to run
>            into failure modes if an object is unrefed too many times.

It does have one weakness, however, in that it's hard to see how it
would allow passing references from one client to another. The other
client would always have to ref, and the previous client would have to
unref. Is that the best and most convenient design? 

Since method calls that return an object reference (including an
object reference other than the one they are referring to) are
supposed to implicitly ref the return value, it seems that in some
cases this won't be feasible. Consider this example:

FooBar_Chunk
FooBar_ChunkRegistry_get_largest_chunk (const CORBA_char  *category,
                                        CORBA_Environment *ev)
{
        FooBar_Chunk retval;
        ....

        /* group is an object implemented in a separate process */
        retval = FooBar_ChunkGroup_get_lead_chunk (group);

        /* what do we do now to make sure that our caller (also in a
        separate process) owns the reference to `group', instead of
        us?) */

        ....
}

Looking at an even simpler example of this problem, who owns the
initial ref when an object is created? oafd owning it is probably not
the right thing.

This is a fundamental issue with the idea of refs having an owner, I
think; you need an abstraction for passing the ref to a new owner. In
traditional mark & sweep garbage collection systems like I worked with
for Guile, this is done by checking what references a given Scheme
holds during the mark phase, since making reference-passing explicit
was just too tricky. The C++ technique for this is to use smart
pointers, where pointer assignment automatically passes or creates a
ref. I don't think either of these approaches works very well over the
wire.

>    I recently found out that in COM, the runtime would actualy keep
> track of the references done for each client.  Upon death of the
> client all the references for that object would be released for
> example.  

Are you sure? When I worked at a company where COM and Windows were
the basis of the application architecture, we always had problems with
leaked references precisely because COM did not do this (because of
the reference passing problem, and the even worse associated problem
you get with DCOM).

>    It is easy to do the code on the BonoboObject side, the only tricky
> part is "detecting" the clients given a CORBA_Object (I have done no
> research at all on this subject, and I am not sure if it is possible).
> 

As Owen said, I'm pretty sure it's not. For one thing, you never know
who has an IOR. It would be valid for a client to write the IOR to
disk, exit and restart, and then try to contact the object again, I
think.


 - Maciej