Re: Lease vs. Refs ...

[Darin Adler <darin bentspoon com>]

On Monday, July 30, 2001, at 02:52  AM, Michael Meeks wrote:

> 	Does that sound like a feasible, semi-permanant solution that
> has some merit ?

Sounds OK to me.

The approach you propose is almost identical to the hack I implemented in 
Nautilus for GNOME 1. The code in nautilus-bonobo-workarounds.c implements 
most of this.

The "immortal" part isn't needed, though. Holding one reference to an 
object makes it sufficiently immortal, unless someone illegally unrefs 
more times than they ref, which is catastrophic in any case. So I'm not 
sure how this feature helps.

On the other hand, destroying an object and disregarding the refs that 
other objects are holding is a tricky business. We had problems with the 
Nautilus implementation. None of the problems were due to the actual 
BonoboObject-killing hack. But there were bugs caused by confusion when an 
in-process control frame sees an in-process control self-destructing 
because the X window is going away. I believe we also had problems with 
ORBit hanging indefinitely rather than promptly returning an exception 
when an object's server was gone.

In the end, we added sloppy timeouts, that I hope we can do without for 
the real Bonobo solution, to help in two ways. First, the timeout 
decreases the possibility of a race condition, even when the code is wrong 
and the race does exist. Second, the timeout guarantees that the code runs 
in the main event loop, so for in-process references, it makes it much 
less likely that an object will disappear between a call to 
bonobo_object_ref and bonobo_object_unref.

I'm eager to see how you handle these details; if this is done right for 
GNOME 2, it will make things much better for Nautilus users!

> 	So - I think, that for many cases we can provide some explicit
> and clumsy way of terminating factories when they are no longer
> needed.

Just a note of clarification about something I am pretty sure we already 
agree on. All of the proposals we're considering use the approach of 
making orphaned objects go away when they are no longer needed. Orphaned 
factory processes then go away because they are no longer serving any 
objects. The factories themselves don't need to be enhanced, just the code 
that manages the lifetime of the objects.

It's much better to make the orphaned objects go away at the right time 
rather than just the factories, because it not only solves the problem of 
extra processes hanging around forever, but also reclaims the memory used 
by the objects even if the factory is still serving other objects.

    -- Darin