Re: investigation into replacing ref. counts with leases



Darin Adler <darin bentspoon com> writes: 
> Easiest for me would be just dropping the whole thing, but I think that without
> this we have big architectural trouble in Bonobo that makes it impractical for
> serious use.
> 
> Maybe there's some better solution to this problem. If I don't get
> any responses to this mail, I'll just drop the whole thing and hope
> that someone else fixes the problem.
> 

By coincidence we were discussing this at lunch today. ;-) But it's a
long-standing debate.

IMO the architectural problem is network transparency. 

You want leases for most out-of-process components, but something else
(a GC scheme, with refcounting as the simplest possible one) for
in-process. There are many other cases where code needs to care about
in-process vs. remote, e.g. it determines whether you have to error
check all method invocations. This is why newer systems such as the
.NET CLR do not have network transparency.

Your patch is kind of an indication of doom; one idea of a component
system is that once you define an interface, it never changes. So by
changing BonoboUnknown, we are changing all interfaces that derive
from it. Oops. We really had to get this right the first time.

One idea for a migration path is to move all current Bonobo to be
in-process, then have add-on support for out-of-process components.

Anyway, I strongly agree with you that out-of-process refcounting is
unworkable.

Havoc




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