[Development] Is QtConcurrent's code generator still in use?

Sorvig Morten Morten.Sorvig at digia.com
Tue Nov 20 14:15:47 CET 2012


On Nov 19, 2012, at 4:42 PM, Thiago Macieira <thiago.macieira at intel.com> wrote:

> On segunda-feira, 19 de novembro de 2012 14.03.17, Konstantin Tokarev wrote:
>>> - The core of a concurrency engine should be a work-stealing data
>>> structure/scheduler. Qt Concurrent  has simple work-stealing
>>> functionality, but is to tied to the global thread pool.
>> Since number of available CPU cores is usually constant over process
>> lifetime (let's forget HPC clusters :), there's nothing wrong with global
>> thread pool.
> 
> By that, you immediately restrict QtConcurrent's use to CPU-bound tasks. One 
> can't use it anymore for tasks that involve blocking I/O, for example.
> 
> Let me give you an example of a thread pool used differently: the DNS resolver 
> code in QtNetwork. It uses 5 threads, regardless of how many CPU cores you 
> have. It involves a blocking call. And as such, it must not use the global 
> thread pool because it would prevent other tasks from running.


Exactly, there must be a way of separating different types of tasks. 

The interesting thing about Qt is that we "own" a complete API, from threading to file system to network stack. This means that the concurrency engine could be informed by the network stack that a worker thread is about to block on I/O.

Morten




More information about the Development mailing list