On Mon, Aug 8, 2011 at 3:20 PM, Thomas Zander <zan...@kde.org> wrote: > On Monday 08 August 2011 21.02.02 Dawit A wrote: >> On Mon, Aug 8, 2011 at 2:31 PM, Thomas Zander <zan...@kde.org> 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?
Yes. The uri filter plugins that are the primary users of this new function require a synchronous function call or they would all have to implement this syncing part individually for themselves.