© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
513534c
demo site
(Get the code!)
When I assigned this to myself I was going to just commit the search regression fixes and call this one fixed as well. However I did some tests over the weekend with something similar to this (patch attached). Tested patch included some other changes (like swapping the guiFuncs vector with a working copy to reduce the need for guiFuncs locks, which reduce the need for _client functions to actually wait for the guiFuncs lock. Though I don't know if that is significant as processGui doesn't hold the lock that long. But that of course caused some lovely problems with deleteEntry).
Anyway processing the gtk events once in a while in the processGui thread helped to keep gui responsive with the cases where pending guiFuncs vector gets too long (joining many large hubs (though don't know if this is an issue still?), receiving search results ~10Mb/s). It doesn't help when single function call takes too long (eg. regrouping >10000 search results). The one thing I have no idea is if it is safe to call gtk_main_iteration inside the gdk_threads_enter? I didn't manage to deadlock it during testing, but that really doesn't tell anything.
Actually now that I think of it, probably some time based solution would be better instead of the call count proposed in the patch.
--RZ