Я написал поток, который выполняет рабочий объект. Все работает нормально. Также результирующие сигналы испускаются так, как должны. Конечно, я позаботился о обычных ошибках в отношении близости ниток/объектов.QSignalSpy не может использоваться нитями
Сегодня я написал автоматизированный модульный тест для этих работников/потоков. Я создал QSignalSpy ждать сигнала, испускаемого объектом рабочего (который был перенесен на нить), как это:
QSignalSpy spy(worker, SIGNAL(Success()));
thread.ExecuteWorker();
QVERIFY(spy.wait()); // Error in this line
Я получаю хорошо известную ошибку в отмеченной линии:
QObject::killTimer: timers cannot be stopped from another thread
Сначала я обнаружил ошибку на моей стороне, потому что какой-то код в wait() был выполнен в неправильном потоке. Тогда я нашел следующий код в реализации QSignalSpy:
if (!QMetaObject::connect(obj, sigIndex, this, memberOffset, Qt::DirectConnection, 0))
{
qWarning("QSignalSpy: QMetaObject::connect returned false. Unable to connect.");
return;
}
Это, очевидно, означает, что QSignalSpy использует DirectConnection все время и не может быть использован для мониторинга сигналов объектов, живущих в разных потоках.
Почему они запрограммировали его таким образом в Qt5.3? Это ошибка или это предполагаемое поведение? Как я могу обойти это ограничение?
Я прочитал ссылки. Особенно интересное размышление ML. Я не уверен, что полностью понял причины, по которым они решили исправить проблему на стороне QTestEventLoop, а не на стороне подключения QSignalSpy. Оба решения разрешили бы проблему, не так ли? – Silicomancer
Потому что поддерживателю это нравилось. – lpapp