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