Re: [g-a-devel] [Accessibility] Re: [Accessibility-atspi] D-Bus AT-SPI - The way forward

[Rob Taylor <rob taylor codethink co uk>]

Michael Meeks wrote:
> Hi Steve,
> 
> On Fri, 2007-12-14 at 18:23 +0000, Steve Lee wrote:
>> plus I was getting almost continuous desktop lockups (and forget
>> using a debugger).
> 
> 	Heh ;-) sure, from my at-poke days I recall a load of methods that
> simply couldn't be called during event emission for various tangled
> reasons (in the gail implementations).
> 
>> Indeed. For example if you want to print events to see what's going on
>> you need to put in a queue to handle it asynch. I've actually now
>> decoupled most processing this way at the risk of occasional timing
>> issues due to the latency
> 
> 	Right - and this is the irony of synchronous event delivery: that at
> some stage, people do this for ~everything anyway ;-). Of course - the
> problem is - switching to a fully async event model (as we had
> initially) ends up with horrible produce/consumer rate mis-matches:
> hence the desire for a 'flow' concept :-)

Righty, I think I know how it'd be possible to have flow control on a
dbus direct connection (custom GSource, message queue limit), but
there's obviously a cost to having a direct connection from each
application to each AT. Though we'd only need to use this direct
connection for sending events so the main cost here (assuming most
people don't run more than 4 AT's) is about 4*cost of sending message
per event (which we kinda have right now with registryd).

Another option is rather than having real flow-control, we could just
mitigate the problem by having an event signal be an array of events and
specifying (say) that event signals should be sent no faster than one
per 1/10 or 2/10 of a second, with some session-wide synchronisation of
the timeouts a-la g_timeout_add_seconds. Of course it would still be
possible to have a producer-consumer rate mismatch, but the control
would be in the hands of the AT, which would know it always has about
1/10 of a second to service an event signal.


What do you reckon?

> 	Having said that, it'd be great to build an understanding of what
> people do synchronously during event emission & can't do elsewhere: to
> add to the events themselves.

Yes! Please let us know, AT coders of the world!

Thanks,
Rob

> 	HTH,
> 
> 		Michael.
> 


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