[Development] Evolving Qt's multithreading API

[Olivier Goffart]

On Tuesday 26 February 2013 20:02:31 Иван Комиссаров wrote:
> My 2 cents. I would like to see something similar to Qt Creator's functions
> implemented in "runextensions.h" in QtConcurrent module itself - methods
> that allows to manipulate future using QFutureInterface (progress
> notification, partial results).
>
> Anyway, i wasn't able to find Qt Concurrent problems, can anyone point them?
> Is it really should be replaced with other solution?

This is just my opinion:

>From an API point of view, I think Qt concurrent is fine. 
One problem is that you cannot select a thread pool for your operations, so 
you are limited to the default thread pool, which means you really should only 
use it for CPU intensive operation.

There are still problem on the implementation:
- In the templated code:  I think the abstractions are on the wrong place. 
This result in a lot of code duplication for the different cases and make also 
the code difficult to follow. (and difficult to modify)
- In the 'engine': Let's say there is room for improvements to limit the 
overhead.  Using lockfree data structures where it make sens, or optimize 
better the code. (at some point one does a median computation that uses a lot 
of CPU)

All of this is fixable.

QtConcurrent was released in a good finished state for a first stable version, 
but it is was still young in a way. Then it could have deserved a bit more 
love over the years. But it stayed as it.

I personally think QtConcurrent should not be replaced.  Just improved.

For example, as you mentioned, incorporating the changes from QtCreator, after 
proper API review.
QtConcurrent::run() (which i feel is what most of this thread is about) could 
possibly be replaced by API in QThread or QThreadPool, to fix the problem that 
it can only be run in the main thread pool.

-- 
Olivier

Woboq - Qt services and support - http://woboq.com