On Wednesday 09 November 2011 18:05:52 Jeremy Lainé wrote: > This talk about QtConcurrent has me wondering: do we need an asynchronous > API at all? > > The underlying system calls are blocking anyway, and we could maybe have a > very simple API like: > > QDnsInfo QDnsInfo::lookup(QDnsInfo::RecordType type, const QString &domain) > > And if you want asynchronous calls you would use QtConcurrent::run(). An > open question: can you use QtConcurrent::run() on a class static method? > > Benefits of this DNS API: > > - QDnsInfo is just a data container (using QSharedData) for an answer, it > does not need to be a QObject and we have very simple ownership semantics > > - the DNS API is not dependent on QtConcurrent, but using them together is > straightforward > > Any thoughts?
I like the idea of a synchronous API in this case, but unfortunatelly QtConcurrent is not up to the task (i'll detail later) And synchronous api would be ok only if it is well documented in the example of the class how to use it assync, and if it is easy enough. So what is wrong with QtConcurrent: - First of all, it is made for CPU intensive task only. Meaning that if you run several querry in parallel, only 1 per core will be executed, the others will be queued. It make no sens to do that for that kind of request. And this is specially bad if some other part of the application is also using QtConcurrent - Second, the use of QFutureWatcher is not the easiest possible (see the number of line of code required when you want to make use of it). One of the problem is that signals/slots do not work with template. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
