[Development] Why is QSignalSpy using Qt::DirectConnection?

Thiago Macieira thiago.macieira at intel.com
Fri Oct 24 18:04:47 CEST 2014


On Friday 24 October 2014 15:41:20 Roland Winklmeier wrote:
> Dear list,
> 
> quick question: I spotted the class QSignalSpy while writing unit tests for
> one of my projects. There was nothing written in the documentation, that it
> is not thread safe and had assumed it is. So I connected signals from a

It is thread-safe if you make it thread-safe. You just have to make sure the 
receiver is in a correct state when you start the other thread or release it 
from a semaphore.

> QObject running in a different thread and got several warnings (timers
> cannot be killed, etc).

Those are your bugs. You can fix them.

> After inspecting its header file, I saw the usage of Qt::DirectConnection.
> 
> if (!QMetaObject::connect(obj, sigIndex, this, memberOffset,
> Qt::DirectConnection, 0)).
> 
> I wonder now if this is intended or the two occurrences can be changed to
> Qt::AutoConnection.

It's intended. The only thing QSignalSpy does in the normal case is to append 
variants to a QList. That's thread-safe. Your warnings came from somewhere 
else.

QSignalSpy::wait() isn't thread-safe because it's using QTestEventLoop instead 
of a regular QEventLoop. That former does use a timer and, unlike the latter, 
you can't stop the loop from outside the loop's own thread.

Maybe what you want is to fix QTestEventLoop.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Development mailing list