On Monday 08 August 2011 21.02.02 Dawit A wrote: > On Mon, Aug 8, 2011 at 2:31 PM, Thomas Zander <[email protected]> wrote: > > On Monday 08 August 2011 18.35.13 Dawit A wrote: > >> #2. The original functions in this class were non-blocking. It is only > >> the new function I added that is a blocking call. And that is required > >> because of the need for a timeout when doing name lookups from the > >> urifilter plugins. Thos plugins perform a job that is time critical > >> and as such cannot be impeded by name lookups that will take too long > >> and hence the need for a timeout. If QHostInfo offered such interface, > >> then there will be no need for the newly added functions. > > > > Maybe naive; but would it not be simpler to wrap the Qt method like this? > > > > const int id = QHostInfo::lookupHost ( hostname, receiver, slot); > > QTimer::singleshot(timeout, QHostInfo::abortHostLookup (id ); > > eh ? The version of QHostInfo::lookupHost you used above is non > blocking so the entire function becomes a non-blocking function which > is not what we want.
In Qt (networking) stuff is non-blocking, which carries over to KDELibs using non-blocking calls. So by my reading we *do* want it to be non-blocking. The main reason I see to use blocking calls is because they are easier to use as a programmer as they allow you to avoid having an extra slot to handle the callback. Am I missing a reason for this case? > Moreover, abortHostLookup is not a SLOT either. > It is simply a static member function. Perhaps I am missing something > here, but I fail to see how this is supposed to work. Right, its not a slot. I missed that :) -- Thomas Zander
