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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.