Re: ref counts & leases ...



On Thursday, July 19, 2001, at 06:31  AM, Michael Meeks wrote:

       Can I ask you to explain quickly how you indicate transferal of
ownership of a reference ? and where in bonobo it has been neccesary to
make this distinction ? and what is the process of transferal ?

There are two levels in my proposal. First consider the CORBA level. Anyone who wants to own an object does a createLease, gets a lease ID, then must do extendLease on a regular basis and destroyLease when ready to relinquish ownership. A lease is in some respects like a ref. Any number of lease holders can exist. There are two differences from refs. One is that each owner has a unique ID for the connection to the object. The other is that a lease goes bad if you don't extend it often enough.

At the higher level, in library calls, C programmers at least don't have to deal directly with the leases. Instead (names here are less refined than the CORBA ones) the bonobo_retain call is used, passing an owner and an owned object. An owner is any pointer. In the case of an object "owned"
 by a global variable, you can just use the address of the global variable.
In the case of an object owned by a GObject, you use the object pointer. Doing a "retain" causes the library to obtain a lease for this object if this process doesn't already have one. Then the library extends the lease as necessary until the last owner in this process does a bonobo_release. Another convenient thing about this C helper level is that bonobo_retain also takes care of the CORBA_Object_duplicate you need to do when you are keeping a CORBA object reference around and bonobo_release does the CORBA_Object_release.

Unlike ref. counts, new objects are not created with an initial lease because existing APIs don't provide a way to pass a lease. In a pinch, factory-type APIs could be changed to return both an object reference and a lease ID, but in practice this will not be necessary. As long as the caller takes ownership of the object from the factory right away, we have no problem. A temporary lease takes care of keeping the object alive until the caller gets it, and if the calling process dies, the temporary lease will eventually expire. The temporary lease goes away when someone takes ownership of the object. (So far this part of the design has not been an issue for existing Bonobo classes that I've looked at. As long as a caller that gets an object from a factory takes ownership of the object on receipt, there's no problem.)

When converting existing code, many calls to bonobo_object_ref turn into calls to bonobo_retain, but others just go away. Most calls to bonobo_object_dup_ref turn into calls to bonobo_retain. But in general fewer of the APIs do transfer of ownership in this model. There's more returning objects that are known to be owned by a particular owner, and less returning of potentially-new objects in a way that transfers ownership. Luckily, Bonobo APIs already have this quality. Factories are few and far between.

Transferring ownership is simple. In the high level API, you just do a new bonobo_retain, then the old owner does a bonobo_release. In the CORBA API, you create a new lease with createLease, then the old owner does a destroyLease. If the old owner is relinquishing ownership for a return value, it just needs to make a temporary lease for the return value time. I haven't settled on the name for this call in the high level API, but in the low level API it just takes the form of an extendLease call with a lease ID of 0.

        Also - like Havoc, I'm rather unconvinced that leases is a full
solution. I think references work extremely well in-proc and leases
presumably very well out of proc.

I'm not sure where this assumption comes from (that the proposed scheme won't work well in-process). When leases don't expire, it has the same semantics as ref. counting, with slightly more overhead. Perhaps there's a problem I'm not seeing, but I don't think so. There's a bit of extra overhead to keep track of the leases, but if we find that we need to optimize that out, we can do that at the bonobo_retain level if CORBA provides a way to distinguish local from remote object references.

        I would prefer if at all possible to have a leasing interface - as
you suggest, but for it to be a separate interface that can be QI'd for,
possibly aggregated by default to aggregates - and handled specialy. And
perhaps used only in special cases - like controls perhaps ?

        Either way, it'd be great to have it as a complimentary technology
like this - rather than a change of this scale ?

        What do you think ?

Any cross-process ref is a bad idea. So any calls to bonobo_object_dup_ref or Bonobo_Unknown_ref represent a potential problem unless the CORBA object is known to be in-process -- but we typically use CORBA objects only in cases where the reference might be cross-process! I suppose we could keep bonobo_object_ref and bonobo_object_unref if we want to support ref. counting for callers on the server side, but we must get rid of the CORBA ref and unref calls (or at least turn them into no-ops). [That does seem like it might lead to a way to make this change compatibly by adding a new interface.]

On the other hand, maybe a separate interface for only selected objects would work. I just imagine that it would be difficult to know when it was and wasn't legal to do the ref and unref. Don't overestimate the magnitude of the change to implement the lease system. I'm not sure that adding it as a new interface would be much simpler, and I suspect that having to do query_interface would actually make it more complex and slower.

But perhaps this approach would work. I wish that someone was available who wanted to do this work though so I didn't have to tackle it myself. Starting in a week or so, I'll have my hands full just porting nautilus and eel.

    -- Darin




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