C++1y (ie whatever the next standard might be called) will likely have even more threading options. Including an "executor" model where you queue up std::functions to be run on background thread(s). But the background threading is "configurable" by the fact that the executor object isn't completely hidden from you (like it is with std::async(), etc).
Maybe we should model something along those lines. I've used that model quite successfully in the past. I can probably find the current proposal(s) in the standards committee if anyone is interested. Tony > -----Original Message----- > From: development-bounces+tvaneerd=rim....@qt-project.org > [mailto:development-bounces+tvaneerd=rim....@qt-project.org] On Behalf > Of Olivier Goffart > Sent: Friday, November 16, 2012 1:37 PM > To: development@qt-project.org > Subject: Re: [Development] The future of QFuture, and QtConcurrent (was > "Is QtConcurrent's code generator still in use?") > > On Thursday 15 November 2012 23:08:39 Sze Howe Koh wrote: > > Thiago also hinted that QtConcurrent development is being minimized > > ("...we're not developing QtConcurrent anymore and shouldn't be > > spending any effort on this than necessary to keep it working" [1]). > > That suggests that the dev team has reached a dead end with the code > > -- although the problems aren't immediately obvious to outsiders. > > > > If the quality of QtConcurrent is subpar and there's little chance of > > improving, then I think it's important to let Qt users know that -- > > through documentation and/or deprecation -- so that they don't > > unwittingly invest their resources in stagnant technology. The > current > > impression I get from the official documentation is that QtConcurrent > > is a high-level alternative to QThread and QRunnable. > > > > QtConcurrent offers the ability to run a function in parallel, and to > > process a container's elements in parallel. The former can be > replaced > > by QRunnable to an extent... but what about the latter? Are there > > strong use cases for parallel container processing, and is it worth > > salvaging that functionality? > > > QtConcurrent is fine, but its implementation has issues. > Both in the "front-end" (the templated code in the headers), and in the > actual > implementation (data structures that don't scale well, ...) > Nothing that cannot really be fixed, but they would need to still re- > think big > parts of QtConcurrent, so that would be a huge work. > > Is this work worth it when there are already others libraries that > offer same > features (if not better) > > ThreadWeaver. Currently part of the KDE libraries. It has been > splitted in a > separate QtAddon as part of the work on KDE Frameworks. > http://api.kde.org/4.9-api/kdelibs-apidocs/threadweaver/html/index.html > > The other option is to use the C++ standard library. C++11 contains > many > threading primitives. http://en.cppreference.com/w/cpp/thread > > -- > Olivier > > Woboq - Qt services and support - http://woboq.com > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
