After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 326545 - decouple event handling
decouple event handling
Status: RESOLVED OBSOLETE
Product: at-spi
Classification: Platform
Component: performance
1.6.x
Other All
: Normal enhancement
: ---
Assigned To: At-spi maintainer(s)
At-spi maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2006-01-10 22:38 UTC by George Kraft IV
Modified: 2014-11-14 21:51 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
original patch (5.39 KB, patch)
2006-09-14 13:11 UTC, George Kraft IV
none Details | Review
revised patch (6.40 KB, patch)
2006-09-14 13:12 UTC, George Kraft IV
none Details | Review

Description George Kraft IV 2006-01-10 22:38:19 UTC
Decouple the events coming from the user application from the events being sent
to the AT for processing.
Comment 1 Bill Abt 2006-01-12 14:17:23 UTC
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.
Comment 2 bill.haneman 2006-01-12 14:22:56 UTC
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!
Comment 3 Michael Meeks 2006-03-15 11:00:13 UTC
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) :-)
Comment 4 George Kraft IV 2006-09-14 13:11:11 UTC
Created attachment 72776 [details] [review]
original patch

Original patch before review.
Comment 5 George Kraft IV 2006-09-14 13:12:02 UTC
Created attachment 72777 [details] [review]
revised patch

Revised patch after review.  Not working.
Comment 6 Li Yuan 2007-11-28 08:42:46 UTC
What is the status of this bug?
Comment 7 André Klapper 2012-02-26 10:45:08 UTC
[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.]
Comment 8 André Klapper 2013-08-14 10:08:33 UTC
[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!]
Comment 9 Magdalen Berns (irc magpie) 2014-11-14 21:51:50 UTC
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.