[Development] API review for a new QDnsResolver class

[Craig.Scott at csiro.au]

On 05/01/2012, at 3:51 AM, Jeremy Lainé wrote:

> Replying to myself to try and get the discussion going again.
> 
> A summary of API decisions so far:
> 
> - we only provide an asynchronous API
> 
> - we do not want a "manager" object (QNAM-style) to avoid users creating a manager per lookup
> 
> - we want a single class to support different types of DNS requests (Q3Dns-style)
> 
> - lookups are performed by calling static methods returning a pointer to a QObject-derived class, which emits the "finished()" signal upon completion

This could be perceived as creating a race condition. You'd have to connect a slot to the signal on the object returned, but what if the signal is emitted before you get a chance to do that? In case you think this is unlikely, we have seen issues like this when running code on virtual machines which seem to have markedly different inter-thread timing behaviour compared to physical machines. You can get longer delays on a thread than you might intuitively expect.


> 
> 
> What remains to be decided:
> 
> - do we want shared pointers or not? My feeling is that using QSharedPointer is going to be awkward for the API user, I cannot find any other example of a Qt API which returns a QSharedPointer to a QObject-derived class.
> 
> - finalise the class name (I think QDns was suggested)
> 
> 
> In the meantime, I have updated my implementation assuming we use raw pointers, with QDnsReply as the working name for the class:
> 
> https://qt.gitorious.org/~sharky/qt/sharkys-qtbase/blobs/8628259746664df7754f7b27d406d7bbd74580b0/src/network/kernel/qdnsreply.h#line154
> 
> 
> Some notes about the implementation:
> 
> - the actual lookup code is run in a thread, managed by a global threadpool (QHostInfo-style)

What happens if the client/user is also employing their own thread pool? Does your implementation simply set some arbitrary number of threads it will use and assume the system will take care of scheduling threads fairly (probably the only safe option)? Are you making use of QThread::idealThreadCount(), in which case it probably won't give the behaviour expected with the client/user also employing their own separate thread pool? Just wondering if using a thread pool here is really buying you anything over simply using QThread directly (but I guess if you are trying to manage supporting a large number of DNS queries then it makes sense to limit how many can be processed at once via a thread pool).

> 
> - the thread and the QDnsReply both operate on a QSharedPointer<QDnsReplyPrivate>, so it doesn't matter whether the QDnsReply is deleted before or after the thread completes
> 
> 

--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia