[Development] API review for a new QDnsResolver class

[Craig.Scott at csiro.au]

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:

(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.

The above scenario is even more likely if there is caching which might make the finished signal get emitted quickly.

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