Re: Refs & Leases ...

[Darin Adler <darin bentspoon com>]

[I removed all of the cc's except for gnome-components-list. One mailing 
list should be enough for this thread.]

On Monday, May 28, 2001, at 02:13  PM, Michael Meeks wrote:

>         As far as I am aware, the prospect of leases is not attractive for
> desktop component software for several reasons:

Most of these assumptions are at least partly wrong, I think. I worked out 
some details of one way to doing this today in my head because I was 
thinking about how nice it would be to remove the hacks in Nautilus that 
try to cope with this problem. It seems pretty simple.

>         * 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. A createLease call returns a unique lease ID, does 
bonobo_object_ref, and creates an entry in a global hash table that maps 
object pointer and lease ID pairs to lease age. An extendLease call sets 
one lease's age to 0. A destroyLease call gets rid of that lease, and does 
bonobo_object_unref if the lease was still pending. A heartbeat timer that 
fires at a given interval (one per process). Each time the heartbeat 
happens, outstanding leases are aged by 1, and if any lease hits the 
maximum age, destroyLease is called.

We then implement new bonobo_unknown_remote_ref and 
bonobo_unknown_remote_unref functions that work on Bonobo::Unknown object 
references for the client side. These are used to implement 
bonobo_object_dup_ref bonobo_object_release_unref, but can be used 
directly if needed. A global hash table maps object pointers (ORBit 
objects, not GtkObjects) to lease ID and reference count pairs. When the 
first ref is done on an object, we do a createLease and store the lease ID.
 When the last unref is done, we do a destroyLease and remove the object 
pointer from the hash table. Using the same heartbeat timer as above, each 
time the heartbeat happens we call extendLease on all leases we hold, and 
then go on to age our outstanding leases as described above.

>         * Horribly inapplicable to in proc case => need 2 lifecycle
>         management systems.

The lease approach I outlined above works for the in-process case. Further 
optimization  is also possible in case it turns out not to be fast enough,
 but I doubt this will be an issue in practice.

>         * Inefficient for lightweight components wrt. memory use

I don't think the overhead for this is going to be excessive compared to 
the overhead that already exists for a BonoboObject. In addition, there is 
no overhead if you don't do a remote ref, and many designs will work fine 
with objects that never involve calls to bonobo_unknown_remote_ref or 
bonobo_object_dup_ref.

>         * Sometimes erroneously destroys valuable components & thus data.

I have no idea how to deal with this -- it's intrinsic to the lease 
concept. But it's the logical flip side to the current distributed ref. 
count design's equally bad problem. With orphaned objects alive forever, a 
machine eventually degrades and has to be "cleaned" before you can 
continue to use it. This is unacceptable for production use on real people'
s computers.

Perhaps we can devise a hybrid solution that uses some non-time-based 
analog to the lease approach when the other process is on the same machine.
 This might require special features in ORBit.

>         Leases are good for some things, but simple as they sound, I don'
> t
> think they solve our problems, still I havn't contemplated leases much so
> I'd appreciate input from anyone on:
>
> > It should be fairly simple for libbonobo to emulate a ref-unref
> > interface but be safer.
>
>         How ? and BTW. the predominantly hub / spoke type referencing we
> have now will turn far more anarchical and cyclic with finer grained
> components.

I have no idea what "anarchical and cyclic with finer grained components" 
means. But what I proposed above *does* seem to solve the problems with 
orphaned components.

If you don't want to start on this yourself because you are not sure it's 
the right direction, I am prepared to write a patch for Bonobo to 
demonstrate the effectiveness of the technique. My guess is that a first 
cut at a working implementation would be less than a day's work.

> 	That's the problem :-) And AFAICS any solutions to this involve
> just as much work as making reference accounting work nicely and reliably
> across process, which is IMHO a nicer model anyway.

I'd love to hear more about what you are alluding to here. It sounds to me 
like something that would be more complicated, but perhaps it's superior 
to the lease approach.

    -- Darin