[Development] API review for a new QDnsResolver class

[Craig.Scott at csiro.au]

On 05/01/2012, at 12:11 PM, 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.

Ah, the reply object emits the signal in the same thread as the caller? I was assuming the signal is emitted from within the thread that is processing the reply. Yes, in that case connecting before returning to the event loop would be sufficient.


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

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