Public bug report changed: https://launchpad.net/malone/bugs/32064
Comment: No thanks, the proper way to fix this bug is removing the cause of deadlock (as was the case with the details hang). Removing threading throws us back to 1.0 days wrt interactivity (where processEvents was done extensively). It is however useless to do so. As for Qt threading, i know what i am doing, thanks again. It is legal to do what i do, there is of course the deadlock issue but that can be fixed. Of course, rewriting the interactivity solution is also violation of feature freeze (and don't think that processEvents doesn't come with its own set of problems like infinite recursion with signal/slot interaction and similar, which are about same problem to debug as threading deadlocks). The parallelism in adept is also a lot more complex than processEvents approach lends itself to, you would end up with same problems i ran into with this in 1.0... Since adept in itself is fairly slow, good interactivity is an absolute must to be usable. Without threads, such a simple thing as a search without results would reliably freeze application until it is finished. Well unless you want to write ugly gui-related hacks into libapt-front. I don't. Oh, it is also far too late in release cycle. For the modification of widgets outside of gui thread. Since you have ripped the code out, you should probably understand that for each thread, there are explicit synchronisation points. These synchronisation points are obviously race-free, since no widget anything is active in the thread at the point of synchronisation. Outside of those synchronisation points, parallel running of threads is prevented by putting everything into a big critical section. Potential problems with all this include spurious call to processEvents() from a non-gui thread (popping up a dialog) -- this was the case with "details freeze", where KDE mime type wanted to pop up an error dialog in a call that firstly looked fairly safe. This is now fixed. The other problem is calls outside of the big critical section -- i believed those that are outside are safe, but apparently kdDebug() tries to lock a mutex so it is obviously not safe. Adding mutex around those calls should solve the problems you are experiencing, i would say? Unfortunately gdb makes debugging deadlocks harder than necessary by not being able to produce proper backtrace... I suspect that removing kdDebug() calls from unlocked threads could even fix this problem. As for debug-enabled build, you can rebuild libapt-front and adept with noopt, nostrip, that should be enough. -- kubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/kubuntu-bugs
