[Development] Evolving Qt's multithreading API

[BRM]

I've been sitting silent on this, but I am quite in favor of having an easy to understand approach to using QThreads, which the proposal in this thread seems to be.

> From: Thiago Macieira <thiago.macieira at intel.com>

> To: development at qt-project.org
> Sent: Monday, February 25, 2013 11:06 AM
> Subject: Re: [Development] Evolving Qt's multithreading API
>>  If so, what's the cost of having two QObjects (trampoline object and
>>  returned object), and how does it compare to the cost of deferring the
>>  start until the next event loop iteration?
>>  In my mind, the costs of 3 different approaches to starting this new method
>>  are:
>> 
>>  - Trampoline object: 2 QObjects, delay of 0 loop iterations, 0 extra
>>  LOC for user
>>  - Queued auto-start: 1 QObject, delay of 1 loop iteration, 0  extra LOC for
>>  user 
>>  - Manual start: 1 QObject, delay of 0 loop iterations, 1 extra LOC for
>>  user
>> 
>>  Which costs the "least"? How do the optimizations to the 
> trampoline
>>  change things?
> 
> Now you're mixing things. First we choose the API: does it start 
> automatically 
> or not? After we've done that, we choose how to implement it and that is an 
> implementation detail.

How about a parameter to the function(s) that specifies whether to auto-start or not; default could be either way.

Personally, I can easily seem myself replacing my current QThread usages with this functionality;
but I'd want to be able to receive both start/finished signals (for logging purposes) and be able to
interact with the QThread object - so the Trampoline object would need to provide an interface by which to
access the internal QThread, or be a pass thru for signals/slots of the QThread.

Of course, I mostly deal with long living threads; but my point of using the new interface would be (i) the simplicity, and (ii) the clarity.

$0,02

Ben