[Development] Evolving Qt's multithreading API

[Sze Howe Koh]

On 21 February 2013 00:02, Rutledge Shawn <Shawn.Rutledge at digia.com> wrote:
> On 20 Feb 2013, at 4:57 PM, Olivier Goffart wrote:
>
>> On Wednesday 20 February 2013 22:45:21 Sze Howe Koh wrote:
>>> Hi all,
>>>
>>> Some time ago there was some talk about improving Qt's multithreading
>>> API. I'm summarizing them here to stop them from fading into
>>> obscurity, and to see if there's any interest in following them up.
>>>
>>> Here are the tasks mentioned:
>>> - Replace/Rewrite QtConcurrent [2]
>>> - Create/Find a good API to replace QtConcurrent::run() for "one-shot" tasks
>>> [1] - Find a third-party solution for high-level multithreading [2]
>>> - Find more uses for QFuture, outside of QtConcurrent [3]
>>> - Influence C++1y by creating a nice multithreading API [4]
>>>
>>> Some suggestions were raised:
>>> - Put a Qt-ish wrapper around TBB [1]
>>> - Integrate ThreadWeaver back into Qt? [2]
>>>
>>> Separately, someone was experimenting with ways to spawn a QObject in
>>> a secondary thread, without first constructing it in the current
>>> thread [5]
>>>
>>>
>>> Do you think any of these avenues are worth pursuing?
>>>
>>> I've had a quick look at TBB vs. ThreadWeaver. The latter specializes
>>> in task-oriented programming, while TBB is a more swiss-army-knife
>>> toolkit, which includes container-based operations similar to
>>> QtConcurrent. So, if we're to integrate 3rd-party option into Qt, TBB
>>> would be more worth it (although it'd involve more work too)
>>
>>
>> Someone has already been working of some feature such as:
>> static QThread::run(QRunable*)
>> static QThread::run(Function)
>> static QThreadPool::run(Function)
>> https://codereview.qt-project.org/#/t/65/
>
> There is also this bug about fixing the examples to show the best practice instead of inheriting from QThread:
>
> https://bugreports.qt-project.org/browse/QTBUG-29059
>
> It sounds like the preferred way will be something different after those patches.

The Qt Project community is divided on what should be the "preferred
way". Some are strongly against subclassing QThread altogether, but
others maintain that subclassing QThread has its valid use cases (see
the actual changes, and the comments in
https://codereview.qt-project.org/#change,45271)

The first group doesn't like subclassing QThread, because it mixes
thread control with threaded code, making it easy for newcomers to
shoot themselves in the foot. The only way around that, currently, is
to use a worker QObject all the time, with queued signal-slot
communication. However, this produces overly-complex code and a big
runtime overhead if you don't actually need an event loop. This, and
the fact that subclassing is normal in C++, is the basis of the second
group's stance. (IIRC, the very frequent foot-shooting led to this
post: http://blog.qt.digia.com/blog/2010/06/17/youre-doing-it-wrong/,
which was rebutted recently with
http://woboq.com/blog/qthread-you-were-not-doing-so-wrong.html)

I was hoping that the new, proposed API can address all concerns.


Regards,
Sze-Howe

P.S. I realize I've made quite sweeping statements about people's
stances; I sincerely hope I've represented all views accurately