[Digikam-devel] Huge threading problems in digiKam?

[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