Re: [Accessibility] a11y / D-Bus / lifecycle ...
Michael Meeks <[email protected]>
| Newsgroups | gmane.comp.gnome.accessibility.devel,gmane.comp.kde.devel.accessibility |
|---|---|
| Organization | Novell, Inc. |
| Message-ID | <[email protected]> |
On Tue, 2007-12-18 at 12:22 +0000, Rob Taylor wrote: > I think we can do *relatively* safe cross-process refcounting with dbus, > but it is going to be pretty heavy - keeping a per-process (actually per > bus-name), per-object reference count in each process and keeping one > reference per bus name on the actual object. Weell ... ;-) yes, if you can fuse the IPC layer and the lifecycle layer (as could not be done in CORBA) this is somewhat possible, though when you have 3 parties involved it's going to get difficult: transfering object ownership from a->b->c is quite exciting, albeit somewhat uncommon: unless you're going to have a separate event broker like at-spi-registryd - which is prolly what you want to do filtering, registration etc. > So, i guess if we do this we need to basically have a general rule of > keeping cross-process refcounting down to a minimum and keep refcounting > of the object proxies and remote object refcounting sepeate. Well, clearly minimising IPC is one thing, but guarenteeing consistency & lifecycle is different & harder. Basically, the distributed reference counting problem is not solved - and all the obvious solutions don't work under some set of circumstances. Are you bearing in mind that all the reference counting pain is to satisfy a situation that doesn't need to exist & should never have been postulated ? :-) [ exposing an entire DOM ]. > I've just taken a quick look at cspi to see what's done there today, and > it seems to have some relatively complex ideas of 'loaning' references. > Can someone explain what's going on here? Sure; that's easy to explain - the idea is to reduce IPC by hiding the remote reference count behind a local reference count. ie. the local AT client can do a hundred ref/unrefs on it's handle and that results in only 2 calls: a ref and an unref :-) The 'loan' concept is to handle references efficiently that we receive during an event emission (AFAIR) - that is more cunning ;-) the basic problem is we get a lot of events containing references which are 'live' only for the lifetime of the synchronous event emission, but we don't want to take a ref on all of them so we do: IPC libspi client -> incoming event create 'borrowed' reference -> on to libspi client code a) client code does a ref ... <- b) check reference - did it get reffed ? yes -> convert to a permanant ref ref <- As you see if a) does not occur, b) does not need to either and we save a round-trip 'ref' call per event emission. HTH, Michael. -- [email protected] <><, Pseudo Engineer, itinerant idiot