Steve Lee wrote: > I'm just adding my 2 cents from what I've been finding as a AT-SPI > nube using pyatspi for Jambu. I started off not thinking much about > interprocess issues and sort of just assumed the event handler was > async and I could do what I like in it. I got a rude awakening when > changes I made affected behaviour in subtle or random ways, plus I was > getting almost continuous desktop lockups (and forget using a > debugger). > > >>> As its stands I've yet to see a real-world usecase for pumping signals >>> faster than user input, though of course, we've tested this case ;). In >>> AT-SPI the event reception is dwarfed by synchronous calls to handle an >>> event, usually to the process that sent the event, so starvation isn't >>> an issue here. >>> > > Populating the file open dialog in gedit in a large directory > generates plenty of event traffic. > > Also I find for simple actions that several of the events you could > expect to occur for completeness are just not there. If this is > addressed it may well result in increased event traffic for simple > application state changes. > > >> Of course - we 'solved' this problem in at-spi by going synchronous >> for >> all events; but ... ;-) that's not such a wonderful solution either. >> > > 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 . At least we can assume reads/writes will > not be pre-empted (I hope). So the onus is on the AT writer to sort it > out. > > Yeah. We use a queue in GOK which we process in an idle handler. I'm doubtful the event traffic coming out of at-spi to the AT could be cut down enough to warrant changing this approach in AT design.
cheers, D _______________________________________________ Gnome-accessibility-devel mailing list Gnome-accessibility-devel@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
