[Interest] QThreads: There's no one way to "do it right"! :)

[André Somers]

Op 23-1-2013 13:08, Bo Thorsen schreef:
> Den 23-01-2013 08:42, Mandeep Sandhu skrev:
>> First I thought "I was doing it right"
>>
>> Then they said "you're doing it wrong"
>> (http://blog.qt.digia.com/blog/2010/06/17/youre-doing-it-wrong/)
>>
>> Then I thought "I _finally_ got it right"!!
>>
>> Now they say "You were not doing so wrong"
>> (http://woboq.com/blog/qthread-you-were-not-doing-so-wrong.html)!! :D
>>
>> End of my Cute poem! :P
>>
>> Jokes apart, which method do most ppl here prefer when doing threading?
> Your question is wrong. Here's why:
>
> I have three ways to use QThread (QtConcurrent not included):
>
> 1) Worker thread that uses moveToThread approach
> 2) Subclass QThread do stuff in run() - no event loop involved
> 3) Subclass QThread and initialize a bunch of objects in run() followed
> by a call to exec()
>
> I'll use any one of them based on what I want to achieve. The third is
> the one that can get the YOU ARE DOING IT WRONG bunch upset. The
> argument against it is that it's probably the most difficult to get
> right, unless you know what you are doing.
Still, I think it is a valid approach indeed, and might need to be 
mentioned in the docs as well.
> There are problems in each approach to using QThread, though. And if a
> developer doesn't understand the issues involved, he will probably end
> up doing something evil - like moveToThread(this).
Qt should probably warn when a user does that... I can't think of a 
valid scenario where that would be needed, at least.
> The reason that #1 is the most popular is that it's the one where
> developers are less likely to shoot themselves in the foot. Which is
> true.
And that's an important argument for documenting QThread the way it has 
been done now. Note that untill Qt 5, the docs basically only showed the 
subclassing (#2) approach. That really has led to issues by users that 
would have been easily avoided by leading them past the 'saver' route #1 
more strongly from the docs to begin with.
> However, if you're on a project with me, there's no way you are
> allowed to use anything as big and powerful as QThread, if you don't
> understand the issues involved with the choices. As the Oracle so
> perfectly states it: "You can never see past the choices you don't
> understand." So it's a somewhat moot point, because I believe strongly
> that anyone using QThread needs to fully understand how objects live in
> the threads and how signals are propagated to slots between objects when
> threads are involved. And when you really understand this, all choices
> are available to you.
Nice in theory, but not possible to uphold in practice, if you ask me. 
Unless you only work with senior developers, perhaps. Anyway, how do you 
expect your developers to learn about all this if you don't give them 
the chance to shoot themselves in the foot? I am a strong believer that 
getting proficient is about doing and learning from and with your peers.
> So if someone just says he prefers one approach over all the others,
> it's because he doesn't fully understand the pros and cons for the
> choices. And that's why your question is wrong. There is no right
> choice. Which fortunately for you is exactly what you had in the mail
> subject :) However, if someone answers that he thinks #1 is more often
> appropriate for the task at hand, then I won't argue against it.
>
> I have answered this before on the mailing list, and I probably will again.
>
> A final note. I have three rules about threading:
>
> 1) Don't do it.
> 2) Don't do it.
> 3) Don't do it yet.
What a silly list of rules. A circular saw is also a dangerous tool, but 
that does not mean you should not use them. It only means that this is 
tool that needs to be yielded more responsively than some other tools. 
Just like there is a place for each of the three ways you mentioned you 
can use QThread, there is a place for using threading in your project as 
well. And I think it is a tool you, as a programmer, better familiarize 
yourself with if you want to be able to write software that will perform 
on todays multi-core systems, no matter how difficult a tool it is to 
yield well.
> If someone on this list is considering threads in their projects, he
> should educate himself to the point where he understands the choices and
> why those three rules makes sense. Then and only then, can he consider
> himself allowed to wield the big hammer :)
Educating oneself is tightly connected to trying your hand at it. Just 
learning from books or documentation pages isn't going to be enough. And 
no, you don't do that for the first time on an important project for a 
customer.

Also, it is easy to say that someone should "educate themselves", but 
that is not a statement suitable for the documentation pages, is it? I 
actually find it somewhat gratuit. Either point people towards the 
sources where they might gain the insights you think people need in 
order to use threads safely, or don't bother to comment this way at all.

André