[Development] The future of QFuture, and QtConcurrent (was "Is QtConcurrent's code generator still in use?")
Sze Howe Koh
szehowe.koh at gmail.com
Thu Nov 15 16:08:39 CET 2012
On 15 November 2012 04:31, Sune Vuorela <nospam at vuorela.dk> wrote:
> On 2012-11-14, Christian Kandeler <christian.kandeler at digia.com> wrote:
>> On 11/14/2012 12:17 PM, Sorvig Morten wrote:
>>> QtConcurrent is done. The implementation is not good enough to be used as a base for further development.
>> Can you be a bit more specific? What are the general problems and why
>> can't they be easily solved?
> I think it is quite limited and hard to use. I recently tried and after
> giving up on that, I switched a project to the ThreadWeaver library by
> KDE which not only made my code simpler, it also made it much easier to
> understand and having threading cote separated out.
> The ThreadWeaver library is a quite simple, but yet powerful thing built
> on qtcore.
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" ).
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?
More information about the Development