GNOME Bugzilla – Bug 326545
decouple event handling
Last modified: 2014-11-14 21:51:50 UTC
Decouple the events coming from the user application from the events being sent to the AT for processing.
I plan on forking the registryd process early on. The initial process will handle registrations as well as process incoming events from applications. However, instead of sending these events to the AT as it does now, it will simply place them in a large semaphore protected queue (in the future, it may be desirable to have a queue per AT but for now a single queue will work). That's all that the initial process will handle. The forked process will be initially in a wait state, waiting for something to be put into the queue. When an item is placed on the queue, the forked process will wake up and dispatch the event. Upon successful dispatch, the semaphore will be obtained and the event will be removed from the queue. If the queue becomes full at anytime, the initial process will begin to purge events from the queue starting with the oldest event (the queue head). In the future, we may want to put some intelligence into how the queue is purged but for the initial release a simple removal of the oldest item will suffice. This solution should result in a decoupling of the event handling and should also make the desktop more responsive in the presence of active AT's. I plan to code and test versions that use fork() as well a g_thread_new() and submit the best performer and most stable for consideration. The difference between the two versions should be minor. The design and goals of both versions will be the same, as outlined above.
MMeeks has recommended the use of two threads rather than a fork(), and I tend to agree. I look forward to seeing an initial patch; thanks Bill!
FWIW - I'd personally recommend 1 thread per client; thus moving the 'overflow' problem to the client side; so we can penalize bad clients by flushing their buffers - but keep good ones fully fed [ or something ]. But either way - looking forward to seeing the patch. Thanks Bill (Abt) :-)
Created attachment 72776 [details] [review] original patch Original patch before review.
Created attachment 72777 [details] [review] revised patch Revised patch after review. Not working.
What is the status of this bug?
[Resetting QA Contact to newly introduced "at-spi-maint@gnome.bugs". Reason: So far it was impossible to watch changes in at-spi bug reports without following all the specific persons (Li Yuan, Bill Haneman, Jeff Wai, ...) and also their activity outside of at-spi reports. IMPORTANT: Anyone interested in following all bug activity (including all maintainers) must watch the "at-spi-maint@gnome.bugs" dummy user by adding it to the 'Users to watch' list under Preferences->Email preferences. This is also the default procedure nowadays in GNOME when setting up new products.]
[Mass-resetting default assignee, see bug 705890. Please reclaim this bug report by setting the assignee to yourself if you still plan to work on this. Thanks!]
I'm going to go ahead and close this because it concerns a very old version. Feel free to open a new bug if the problem persists.