Re: [g-a-devel] [Accessibility] a11y / D-Bus / lifecycle ...
- From: Michael Meeks <michael meeks novell com>
- To: Rob Taylor <rob taylor codethink co uk>
- Cc: gnome-accessibility-devel <gnome-accessibility-devel gnome org>, accessibility-atspi-linux-foundation <accessibility-atspi lists linux-foundation org>, Mark Doffman <mark doffman codethink co uk>, kde-accessibility <kde-accessibility kde org>, accessibility-linux-foundation <accessibility lists linux-foundation org>, Li Yuan <Li Yuan Sun COM>
- Subject: Re: [g-a-devel] [Accessibility] a11y / D-Bus / lifecycle ...
- Date: Tue, 18 Dec 2007 12:46:09 +0000
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.
--
michael meeks novell com <><, Pseudo Engineer, itinerant idiot
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]