On 21 February 2013 00:02, Rutledge Shawn <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
