[Development] The future of QFuture, and QtConcurrent (was "Is QtConcurrent's code generator still in use?")

Tony Van Eerd tvaneerd at rim.com
Thu Nov 15 22:07:09 CET 2012

- needs new docs (coming in 5.0)
- often misused ("you're doing it wrong")
- results in too many dedicated threads (typically)
- or threads created/destroyed too often

- I thought this was a better alternative for "one shot tasks"
- now it sounds like QtConcurrent is not the way to go?

What should I be recommending to developers?

> -----Original Message-----
> From: development-bounces+tvaneerd=rim.com at qt-project.org
> [mailto:development-bounces+tvaneerd=rim.com at qt-project.org] On Behalf
> Of Sze Howe Koh
> Sent: Thursday, November 15, 2012 10:09 AM
> To: development at qt-project.org
> Subject: [Development] The future of QFuture, and QtConcurrent (was "Is
> QtConcurrent's code generator still in use?")
> 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" [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?
> Sze-Howe
> [1] https://codereview.qt-project.org/#change,39375
> _______________________________________________
> Development mailing list
> Development at 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.

More information about the Development mailing list