[Development] Evolving Qt's multithreading API

[Rutledge Shawn]

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.