Re: Refs & Leases ...
- From: Darin Adler <darin bentspoon com>
- To: Michael Meeks <michael ximian com>
- Cc: gnome-components-list gnome org
- Subject: Re: Refs & Leases ...
- Date: Mon, 28 May 2001 23:06:32 -0700
[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
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
* 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'
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
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.
] [Thread Prev