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. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
