Re: Refs & Leases ...

[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


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'
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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]