Op 22-2-2013 14:31, Corentin Jabot schreef: >> On second thought, I'm not sure if this would be commonly needed. We >> can make it start immediately instead, BUT this requires a guarantee >> that the first thread can always connect the finished() signal, before >> the new thread runs and finishes. Can that be guaranteed? > Think about QNetworkAccessManager : > reply = nam->get(url); // start the request > connect(reply, QNetworkReply::finished(), doSomething()); // you can > connect later > > I think that work just fine because the connection is queued, > But I'm not sure exactly how. It works for QNAM, because the request is guaranteed to be made async. The work is only started when control is returned to the eventloop. For this to work in the threading context, you'd have to make a similar guarantee. Otherwise, you might end up in the situation that you start the thread, and before the connection is made, the thread already finishes, resulting in the slot never being called. That would result in only starting the work in the other thread when either the result is requested, or control is returned to the eventloop so you're sure all connectes are made.
Alternatively, you'd have to start doing the work explicitly as written here: > >> If not, >> we'll need: >> >> QThread *thread = QThread::runFunction([]() { return >> doSomethingComplicated(); }); >> connect(thread, &QThread::finished, this, &MyObject::doStuff); >> thread->start(); // Manual start, after all connections have been made >> >> OR >> >> QThread *thread = QThread::runFunction([]() { return >> doSomethingComplicated(); }); >> thread->wait(); // Wait for auto-started thread to end >> doStuff(); >> >> The latter is like Corentin's approach using QFuture. Which is better? >> (Personally I think the latter defeats the purpose of having a 2nd >> thread) > Of course that was a silly example, you would connect the QFuture > finished signal > to a slot, or use QFutureSynchronizer to run run multiple treatments > concurrently. > If only QFuture allowed you to connect... Unfortunately, it is not a QObject. André _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development