[Development] Evolving Qt's multithreading API

[André Somers]

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é