Huge threading problems in digiKam?

Hi,

we have so many crashes in digiKam and all seem to be related to something
running inside a thread.

I also received a mail from André Wöbbeking ([hidden email]) where he
claims that digiKam seems to do a lot of errors with QThreads.

I then ran digiKam with helgrind and I get millions of data races etc, which
could prove the threading errors we might have.

I'm no expert in threaded applications, nor am I very familiar with the
QThread mechanism, so maybe we should really take a look at this now, before
releasing 1.0.0.

I will try to translate André's mail (it was written in German) and attach it
to this thread.

Andi
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

translated mail by André:



Hi Andi,

since a long time digiKam is crashing when loading thumbnails from the camera
(take a look at the attached backtrace).

I took a look at the CameraUI and CameraController code and I think you have a
general threading problem.
Both objects are running in separate threads, but the signals/slots
connections are not queued. Therefore the CameraUI slots seems to be running
in the CameraController thread.

The best solution would be to have a class derived from QObject, that has the
signals of the CameraController. This class should than be initialized in the
CameraController::run() method. If you connect this class in CameraUI, all
connections will be automatically queued. Another advantage of this new class
would be to have a clear separation of the two threads.
At the moment it is not clear which signals / slots are running in which
thread.

Maybe you have similar problems in other threads as well, the B.K.O. seems to
be full of such crash reports.

André


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> The best solution would be to have a class derived from QObject, that has
>  the signals of the CameraController. This class should than be initialized
>  in the CameraController::run() method. If you connect this class in
>  CameraUI, all connections will be automatically queued. Another advantage
>  of this new class would be to have a clear separation of the two threads.
> At the moment it is not clear which signals / slots are running in which
> thread.

I have seen this understanding of AutoConnection in other parts of KDE.
The documentation states:

"Qt::AutoConnection:
If the signal is emitted from the thread in which the receiving object lives,
the slot is invoked directly, as with Qt::DirectConnection;
otherwise the signal is queued, as with Qt::QueuedConnection."

Note that the thread of the sending object is not mentioned.

The logic in Qt's source code is as follows:

if ((c->connectionType == Qt::AutoConnection
        && (currentThreadData != sender->d_func()->threadData ||
                receiver->d_func()->threadData != sender->d_func()->threadData))  ||
      (c->connectionType == Qt::QueuedConnection)) {
        queued_activate(sender, signal, *c, argv);

The signal will be queued if sender and receiver are living in different threads,
or if they live in the same thread but the current thread is different.
(IMO the docs are slightly wrong when receiver lives in the current thread
but not sender, it will be queued then)

So I argue that it is not necessary to create an object living in the emitting thread,
emitting signals will just to the right thing.

Marcel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel