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