Re: [g-a-devel] [Accessibility] Re: [Accessibility-atspi] D-Bus AT-SPI - The way forward
- From: Michael Meeks <michael meeks novell com>
- To: Steve Lee <steve fullmeasure 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>
- Subject: Re: [g-a-devel] [Accessibility] Re: [Accessibility-atspi] D-Bus AT-SPI - The way forward
- Date: Mon, 17 Dec 2007 13:14:41 +0000
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 :-)
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.
HTH,
Michael.
--
michael meeks novell com <><, Pseudo Engineer, itinerant idiot
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]