[Development] API review for a new QDnsResolver class

[Olivier Goffart]

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.