O Martes, 5 de Marzo de 2013 11:53:13 Frank Reininghaus escribiu: > I'm not a network expert, and I don't know what the cause of the > problem is, but I noticed two things: > > 1. I think the access to "m_request" in FakeServer::*Request() needs > to be protected by locking m_mutex. Doing that does not seem to fix > the issue, but not protecting it might lead to other problems at some > point. > > 2. The class FakeServer follows the "You're doing it wrong" pattern > (it contains the line "moveToThread(this);") , see > > http://blog.qt.digia.com/blog/2010/06/17/youre-doing-it-wrong/ > http://woboq.com/blog/qthread-you-were-not-doing-so-wrong.html > > This might or might not be part of the problem.
Many thanks for the input! I think I’ve solve both issues, but the race condition persists. I’ve uploaded a tar.xz with the current state of the test files to Gitorious: https://gitorious.org/libmediawiki/libmediawiki/blobs/raw/gallaecio/examples/raceissue/2ndAttemptToAvoidRaceCondition.tar.xz The files can also be found at https://gitorious.org/libmediawiki/libmediawiki/trees/gallaecio/examples/raceissue I followed the lead of the Qt documentation, and the main function looks like this now: int main(int argc, char* argv[]) { QCoreApplication a(argc, argv); QThread *serverThread = new QThread(); FakeServer *fakeserver = new FakeServer; QObject::connect(serverThread, SIGNAL(started()), fakeserver, SLOT(run())); QObject::connect(serverThread, SIGNAL(finished()), fakeserver, SLOT(deleteLater())); fakeserver->moveToThread(serverThread); serverThread->start(); for (int i = 0; i < 10000; i++) { Job job; job.exec(); QList<FakeServer::Request> requests = fakeserver->getRequest(); if (requests.size() != 1) qDebug() << requests.size() << "? WTF?"; else qDebug() << requests.size() << ", as expected."; fakeserver->clearRequest(); } serverThread->quit(); return 0; }
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
