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

[Thiago Macieira]

On terça-feira, 20 de novembro de 2012 13.15.47, Sorvig Morten wrote:
> > 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.

Indeed, we can do that. But right now, telling QtConcurrent that the thread is 
going to sleep / block means it will schedule a new thread to continue 
processing tasks. We don't want that for the DNS resolver: we want to limit 
the number of queries in parallel for a reason.

And even if that were not the case, we wouldn't want to share the global 
thread pool: even if the user is busy creating thumbnails for an image 
collection, we still want to send DNS requests to find flickr.com.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121120/a7802bd6/attachment.sig>