Review Request: Replace thread usage with local event loop in kio/kio/hostinfo.cpp

Thomas Zander zander at kde.org
Mon Aug 8 20:20:47 BST 2011


On Monday 08 August 2011 21.02.02 Dawit A wrote:
> On Mon, Aug 8, 2011 at 2:31 PM, Thomas Zander <zander at 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?

> 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




More information about the kde-core-devel mailing list