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

[Thomas Zander]

On Monday 08 August 2011 21.28.45 Dawit A wrote:
> On Mon, Aug 8, 2011 at 3:20 PM, Thomas Zander <zander at 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 <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?
> 
> 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.

Apologies for still not getting it..
You stated you wanted to have a timeout to avoid a blocking UI, which as far 
as I understand you would also avoid if you don't create a new method that 
never blocks in the first place.

My confusion lies in the idea that the new lookupHost method  introduces 
blocking which we both agree will be bad for UI responsiveness.
Using non-blocking callbacks using the main threads eventloop sounds like its 
the way to go, then.
It doesn't have to be very complicated for those plugins to do; some of those 
uri filter plugins can use the trick of a QTimer if thats what they want.
There are other solutions too, I guess I can google for other usages of this 
Qt class on the net and see what others did.

Maybe that solution is less complicated then creating an extra thread?
-- 
Thomas Zander