[Bug 32064] Unable to launch adept on AMD64 - Flight 4

[mornfall]

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.