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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
