[Development] Evolving Qt's multithreading API

[BRM]

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

> To: development at qt-project.org
> Cc: 
> Sent: Tuesday, February 26, 2013 10:46 AM
> Subject: Re: [Development] Evolving Qt's multithreading API
> 
> On terça-feira, 26 de fevereiro de 2013 07.03.37, BRM wrote:
>>  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.
> 
> Why? Why do you need access to the QThread object? Please don't answer the 
> started / finshed signals -- those will be provided.

Querying the status of the thread, and waiting for termination - e.g. QThread::wait(); or connecting a signal to tell it to quit.
Having a minimal API is great for creating it; but you may still need access to the other functions provided by the QThread API.
Either direct access or a pass-thru API would suffice; but it's probably a lot easier to have:

QThread* Trampoline::getThread() const;

than to do all the signals/slots/etc in the Trampoline object.

$0.02

Ben