On 22 February 2013 21:58, André Somers <[email protected]> wrote: > Op 22-2-2013 14:31, Corentin Jabot schreef: >> 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.
Hmm... I haven't looked at the implementation of QNAM, but what if, during the construction of the new QThreads (specifically, subclasses that handle functions/QRunnable), the derived QThreads post their start() method to the event loop? Will that delay the starting until control returns to the event loop? Regards, Sze-Howe _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
