[Development] Evolving Qt's multithreading API

[Sze Howe Koh]

On 22 February 2013 21:58, André Somers <andre at familiesomers.nl> 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