[Development] API review for a new QDnsResolver class

[Thiago Macieira]

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.

> (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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120104/528a3ed3/attachment.sig>