On 05/01/2012, at 12:11 PM, Thiago Macieira wrote: > On Thursday, 5 de January de 2012 12.07.37, craig.sc...@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.sc...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development