Re: [g-a-devel] [Accessibility] a11y / D-Bus / lifecycle ...

[Rob Taylor <rob taylor codethink co uk>]

Michael Meeks wrote:
> 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.

Well, 'fuse' is a pretty strong term, 'predicated on' would be more
correct. Its simply possible because there's a bus that tells you when
connections go away, and you always know what connection a message comes
from.

Why would you need to have an ownership scheme? surely just plain old
refcounting is sufficient? Though that raises an interesting point, you
couldn't have floating refs for object references in signal emissions,

>> 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.

aye, but we only need to worry about certain circumstances, surely?
basically its solely for keeping an ATK object alive for a given DOM
object, right?

> 	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 ].

Indeed I am, but I haven't had a brainwave on a better solution. Got any
ideas?

Actually I'm not really convinced that exposing the DOM necessarily
implies reference counting, we still have the base lifecycle management
of the 'page' being 'visible' surely? Its simply a matter of how
efficient exposing the dom is, and a dbus-basing interface would imply
that we don't need real objects representing the members of the DOM,
gecko could just talk dbus directly. (Obviously this is more work than
just being able to plug into the current ATK stuff though)

>> 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.

Thanks for the low-down!

Rob
> 	HTH,
> 
> 		Michael.
> 


-- 
Rob Taylor, Codethink Ltd. -  http://codethink.co.uk