[Development] API review for a new QDnsResolver class

[aaron.kennedy at nokia.com]

Hi,

On 05/01/2012, at 1:11 AM, ext Thiago Macieira wrote:

> On Thursday, 5 de January de 2012 12.07.37, Craig.Scott at csiro.au wrote:
>> On 05/01/2012, at 11:47 AM, Thiago Macieira wrote:
>>> On Thursday, 5 de January de 2012 11.03.42, Craig.Scott at csiro.au wrote:
>>>> 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?
>>> 
>>> It cannot happen if you make it, by design, not possible.
>>> 
>>> That means the reply object must ensure that it never processes replies
>>> before first returning to the user. If a result was found cached (if ever
>>> there's a cache), then we need to be able to tell the user that the reply
>>> has already finished.
>> 
>> Even if it never processes replies before first returning the user, there is
>> the possibility of a race condition:
> 
> No, there isn't. Your scenario below implies the user willfully connected 
> late. All you need to do is connect the signal before returning to the event 
> loop. That's how QNetworkReply ensures it works.

You can avoid the signal-connection race condition like this, and it does work well in QNetworkReply.

However, it is a little frustrating as a programmer that you have to connect signals and slots (not the fastest things in the world), and unnecessarily reenter the Qt event loop when you know that the data is often already available.  If you expect the DNS lookups to be cached, perhaps you should follow the simple pattern that QDeclarativeComponent uses - where we have an isReady() method that you check, and only if that is false do you need to connect to the signal.

Cheers,

Aaron


> 
>> (1) Reply object is returned to the user.
> 
>> (2) Reply object processes the request and emits the relevant finished
>> signal in its own thread. 
> 
>> (3) Caller adds a signal-slot connection (could
>> be on the line immediately following the function call that returned the
>> reply object), but the signal has already been missed.
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
>     Intel Sweden AB - Registration Number: 556189-6027
>     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development