Re: Refs & Leases ...

[Darin Adler <darin bentspoon com>]

On Tuesday, May 29, 2001, at 04:59  AM, Michael Meeks wrote:

> The primary issue with all these schemes is that of handing
> references, since it blows the model of reference ownership out of the
> water. So, whatever scheme we use needs some way to hook return and out
> values from stubs and skels, and deal with them appropriately. So, no. 1
> job is:
>
> * ORB hooks [1]

If the design does require ORB hooks, then it blows my "can do it easily in 1 day" estimate out of the water. Lets call my existing proposal "proposal A".

I don't think that every function that returns an object needs to return a object that's referenced. For example, Bonobo::Control::getControlFrame should not return one. On the other hand, functions that do return new objects need to somehow hand over ownership, and the current design uses a single reference to do that.

My thinking is that since ORB hooks can't distinguish these two cases, we may want to devise a design that doesn't rely on them. In the lease design, perhaps we can create a lease for return value purposes. It's the caller's responsibility to take ownership by doing a ref., but the lease created for the purposes of returning a new object makes it last long enough to successfully do that ref.

So functions that create new objects would have to call a special function, bonobo_object_ref_for_return_value (or some simpler name). Let call this expanded version "proposal A'".

> > > * Total interface re-design
> >
> > Unnecessary.
> >
> > The interface change is that ref and unref are removed from
> > Bonobo::Unknown, and we add createLease (returns a lease ID),
> > extendLease, and destroyLease.
>
> Of course, there is no particular neccessity to remove
> Bonobo::Unknown, we could have a parallel leasing system layered on top: a
> Bonobo::Lease interface ?

I guess that's OK. I do worry though that if you retain public ref and unref operations it makes it hard to tell if code has been converted over to the lease mechanism. If the operations are still around it's possible to "use things wrong" whereas if they are removed then that's quite difficult.

Note that the whole process of moving to the new API requires changing any code that calls ref and unref through the CORBA object reference, and the new scheme makes it illegal to do such a ref. Only the server side is allowed to do refs and unrefs.

> Also, what is the purpose of the 'lease ID' ? why can we not use
> the object reference to renew the lease ? - are you worried about tracking
> erroneous lease destroys ?
>
> I suppose as a destruction mechanism, it is better to have a
> synchronous leaseDestroy method than a 'just wait for the timeout' type
> destruction process.

The reason proposal A uses a lease ID is so that one lease can be explicitly destroyed without disturbing other still-outstanding leases on the same object. This is required only because of multiple ownership implied by allowing multiple processes to each do a bonobo_remote_object_ref.

The synchronous leaseDestroy is indeed important. Always waiting for the timeout seems like it would be no good.

> Notably, your job could possibly be made much easier by hooking
> into the CORBA ref counting, since this seems to follow similar semantics
> to that wish you wish to implement.

If you are referring to the ref. counting used so that a single CORBA object reference is shared, I should point out that such an object reference should not be strong enough to keep the referenced object alive. We don't want every CORBA object reference to count as a ref/lease.

> I mean, disorganised, ie. with not so trivial a topology as is
> seen in Nautilus, a simple container / containee relationship / ownership
> structure. Designing a system to deal with this setup is conceptualy easy
> since the reference ownership seems to be clear.

You say "as seen in Nautilus", but I should note this container / containee relationship comes from the design of the Bonobo classes, not really from anything specific to Nautilus. I can't find any more-complex relationships in today's Bonobo. I don't doubt that someone will want to build more-complex stuff, but I intend that it be designed around a robust concept of object ownership, not simple ref. counting and wishful thinking.

Today's Bonobo classes all have these single owner/owned relationships: BonoboEmbeddableFrame/BonoboEmbeddable, BonoboControlFrame/BonoboControl, BonoboControl/BonoboUIComponent.

And note also that most of today's Bonobo objects don't need to have ownership relationships that span processes. A BonoboPropertyBag or BonoboUIContainer does not need a possibly-remote owner, or does a BonoboControlFrame. It's enough that the possibly-remote client can get an object reference and perform operations on that object.

Give this, perhaps we should consider an even simpler API with only single owners. Lets call it "proposal B".

We can eliminate the concept of cross-process reference counting completely, and simply replace ref and unref with extendLease and endLease in Bonobo::Unknown. Calls that return an object that comes with a ref in today's API would simply extend the lease on the object before (unref'ing and) returning it.

The client-side convenience calls would be:

Bonobo_Unknown bonobo_begin_lease(Bonobo_Unknown);
void           bonobo_end_lease(Bonobo_Unkown);

bonobo_begin_lease would do a Bonobo_Object_duplicate, call extendLease immediately, and put the object on a list to get an extendLease with each heartbeat. bonobo_end_lease would remove the object from the extendLease list, do an endLease, and then do a Bonobo_Object_release. Calls that would be removed would be BonoboObject::ref, BonoboObject::unref, bonobo_object_dup_ref, and bonobo_object_release_unref. 

The restriction here is that there can be only one lessor per object. But this fits perfectly with today's Bonobo classes.

I'm thinking it may be more worthwhile to experiment with proposal B rather than trying for proposal A', because proposal B has a real promise for working properly for return values.

Your thoughts?

> Ok, so reference accounting works on a connection basis - again
> you need hooks into the ORB, and to fix the return / out value mess. Then
> foreach connection you maintain a count of how man references it owns
> [2]. When the connection is broken [ which is already detected ], you
> remove all refs that have come in from that connection.
>
> The issue with this is that all ref / unref traffic on the object
> that is given out via that connection, must come back through that
> connection. ie. if A passes O to B then A maintains B's refs on O against
> it's connection to B. if B passes O to C, then any refs C does must go via
> B in order to maintain the 'connection' concept of ownership - either that
> or more complexity is needed to attempt to re-map reference ownership to
> other connections - a pain.

Proposal A has the same problem with return values, and has similar restrictions about all ref/unref happening on the same connection.

> [1] - NB. Of course, some might think that ths is not a problem, since if
> you ref in the server you have a lease refreshing idle handler running on
> the server, thus the client can have a ref and not need a refresh handler,
> and when the client does a destroy_lease everything will be ok. Problem is
> if the client just dies we have leaked a ref [ just as with reference
> counts ].

We can indeed use a lease to make the returned object last long enough to get a new owner, but sadly in proposal A' we would have to wait for that lease to expire rather than relying on the explicit destroy.

-- Darin