[Development] Evolving Qt's multithreading API

[Joseph Crowell]

On 2/27/2013 2:12 AM, BRM wrote:
>> 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
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
I have threads that live for the full life of my application but telling 
them to stop on application shut down is painful. For this reason I 
would like to be able to cancel a thread and also have a virtual 
function to handle what happens when tread cancel is requested.. i.e. 
cleanly closing child objects and handling locked mutexes so I don't get 
segfaults. This is possible with current QThread but could be much easier.