Re: Refs & Leases ...

[Michael Meeks <michael ximian com>]

Hi Darin,

On Mon, 28 May 2001, Darin Adler wrote:
> 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.

	Great. As always a simple solution sounds ideal, thanks for your
thoughtful input.

	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]

> >         * 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 ?

	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.

	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.

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

	Clearly, no-one is arguing with that.

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

	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.

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

	Wow, yes - I am very interested in this, and of course - if it
works well and is as simple as it sounds of course, I'd be extremely
pleased with merging it up. I would suggest though that leaving
Bonobo::Unknown around might be a good plan, and using that as your base
lifecycle management techology [ purely for use by the leases ]: This
might also make it applicable to Gnome 1.4 and 2.0.

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

	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.

	To make the above scheme work well, [ which incidentaly is what
UNO uses ], we would need to consider carefuly how best to organise
activation to minimize masses of chained reference passing [ this is the
obvious hole in the ref counting scheme - apart from the issue of an
intermediate process going away ].

	Anyhow, I'd very much welcome a simpler solution.

	Regards,

		Michael.


[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 ].

[2] - ie. ownership is transfered for returns / outs.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot