[Development] Evolving Qt's multithreading API

[d3fault]

On Sun, Mar 3, 2013 at 10:15 AM, Sze Howe Koh <szehowe.koh at gmail.com> wrote:
> On 27 February 2013 15:38, Laszlo Papp <lpapp at kde.org> wrote:
>>
>> On Wed, Feb 27, 2013 at 1:13 AM, Joseph Crowell <joseph.w.crowell at gmail.com> wrote:
>>>
>>> I have threads that live for the full life of my application but telling
>>> them to stop on application shut down is painful.
>>
>>
>> What a coincidence. I have just had the same scenario. :-)
>
> How did you guys solve this issue? Do you need different cleanup code
> for the "cancelled halfway" case and the "finished naturally" case?
>

That depends too much on your specific design to be able to be
answered. If your slots can schedule more slots (for example), then
they might receive a quit message in between two slots that depend on
each other and the thread could be brought down "halfway" because the
second slot is never entered... and maybe some relevant data corrupted
(in that case, you would have to use flagging to cleanly shutdown,
which isn't too difficult but turns your code into a spaghetti of
paths).

I wrote a clean threading example for my own reference a while ago.
Took quite a bit of reading the documentation, but once you know what
you're doing (a lot of which depends on proper design of your backend
thread/object), it's not too hard to tell them to stop at application
shutdown. Here's that example demonstrating clean shutdown:
http://lists.qt-project.org/pipermail/interest/attachments/20121026/60482ba0/attachment.zip

In that project I was also working on my own "evolution" of the
threading API but eventually gave up after I deemed fighting qmake/moc
to be a waste of time. Was pretty close to getting QThread to be able
to target a Functor with some args etc like has been mentioned in this
thread. That's what Qt's threading solution is really missing.


d3fault