Re: ref counts & leases ...

[Darin Adler <darin eazel com>]

On Thursday, July 19, 2001, at 06:31  AM, Michael Meeks wrote:

>        Can I ask you to explain quickly how you indicate transferal of
> ownership of a reference ? and where in bonobo it has been neccesary to
> make this distinction ? and what is the process of transferal ?

There are two levels in my proposal. First consider the CORBA level. 
Anyone who wants to own an object does a createLease, gets a lease ID, 
then must do extendLease on a regular basis and destroyLease when ready to 
relinquish ownership. A lease is in some respects like a ref. Any number 
of lease holders can exist. There are two differences from refs. One is 
that each owner has a unique ID for the connection to the object. The 
other is that a lease goes bad if you don't extend it often enough.

At the higher level, in library calls, C programmers at least don't have 
to deal directly with the leases. Instead (names here are less refined 
than the CORBA ones) the bonobo_retain call is used, passing an owner and 
an owned object. An owner is any pointer. In the case of an object "owned"
 by a global variable, you can just use the address of the global variable.
 In the case of an object owned by a GObject, you use the object pointer. 
Doing a "retain" causes the library to obtain a lease for this object if 
this process doesn't already have one. Then the library extends the lease 
as necessary until the last owner in this process does a bonobo_release. 
Another convenient thing about this C helper level is that bonobo_retain 
also takes care of the CORBA_Object_duplicate you need to do when you are 
keeping a CORBA object reference around and bonobo_release does the 
CORBA_Object_release.

Unlike ref. counts, new objects are not created with an initial lease 
because existing APIs don't provide a way to pass a lease. In a pinch, 
factory-type APIs could be changed to return both an object reference and 
a lease ID, but in practice this will not be necessary. As long as the 
caller takes ownership of the object from the factory right away, we have 
no problem. A temporary lease takes care of keeping the object alive until 
the caller gets it, and if the calling process dies, the temporary lease 
will eventually expire. The temporary lease goes away when someone takes 
ownership of the object. (So far this part of the design has not been an 
issue for existing Bonobo classes that I've looked at. As long as a caller 
that gets an object from a factory takes ownership of the object on 
receipt, there's no problem.)

When converting existing code, many calls to bonobo_object_ref turn into 
calls to bonobo_retain, but others just go away. Most calls to 
bonobo_object_dup_ref turn into calls to bonobo_retain. But in general 
fewer of the APIs do transfer of ownership in this model. There's more 
returning objects that are known to be owned by a particular owner, and 
less returning of potentially-new objects in a way that transfers 
ownership. Luckily, Bonobo APIs already have this quality. Factories are 
few and far between.

Transferring ownership is simple. In the high level API, you just do a new 
bonobo_retain, then the old owner does a bonobo_release. In the CORBA API,
 you create a new lease with createLease, then the old owner does a 
destroyLease. If the old owner is relinquishing ownership for a return 
value, it just needs to make a temporary lease for the return value time. 
I haven't settled on the name for this call in the high level API, but in 
the low level API it just takes the form of an extendLease call with a 
lease ID of 0.

>         Also - like Havoc, I'm rather unconvinced that leases is a full
> solution. I think references work extremely well in-proc and leases
> presumably very well out of proc.

I'm not sure where this assumption comes from (that the proposed scheme 
won't work well in-process). When leases don't expire, it has the same 
semantics as ref. counting, with slightly more overhead. Perhaps there's a 
problem I'm not seeing, but I don't think so. There's a bit of extra 
overhead to keep track of the leases, but if we find that we need to 
optimize that out, we can do that at the bonobo_retain level if CORBA 
provides a way to distinguish local from remote object references.

>         I would prefer if at all possible to have a leasing interface - as
> you suggest, but for it to be a separate interface that can be QI'd for,
> possibly aggregated by default to aggregates - and handled specialy. And
> perhaps used only in special cases - like controls perhaps ?
>
>         Either way, it'd be great to have it as a complimentary technology
> like this - rather than a change of this scale ?
>
>         What do you think ?

Any cross-process ref is a bad idea. So any calls to bonobo_object_dup_ref 
or Bonobo_Unknown_ref represent a potential problem unless the CORBA 
object is known to be in-process -- but we typically use CORBA objects 
only in cases where the reference might be cross-process! I suppose we 
could keep bonobo_object_ref and bonobo_object_unref if we want to support 
ref. counting for callers on the server side, but we must get rid of the 
CORBA ref and unref calls (or at least turn them into no-ops). [That does 
seem like it might lead to a way to make this change compatibly by adding 
a new interface.]

On the other hand, maybe a separate interface for only selected objects 
would work. I just imagine that it would be difficult to know when it was 
and wasn't legal to do the ref and unref. Don't overestimate the magnitude 
of the change to implement the lease system. I'm not sure that adding it 
as a new interface would be much simpler, and I suspect that having to do 
query_interface would actually make it more complex and slower.

But perhaps this approach would work. I wish that someone was available 
who wanted to do this work though so I didn't have to tackle it myself. 
Starting in a week or so, I'll have my hands full just porting nautilus 
and eel.

    -- Darin