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 _______________________________________________ Gnome-accessibility-devel mailing list Gnome-accessibility-devel@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
