[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