[Development] API review for a new QDnsResolver class

Jeremy Lainé jeremy.laine at m4x.org
Thu Jan 5 07:42:40 CET 2012


On 01/05/2012 01: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.

As you stated, the reply object lives in the calling thread, and the finished() signal is 
always emitted in a queued fashion, so I think we're OK.

Jeremy



More information about the Development mailing list