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

[Olivier Goffart]

On Tuesday 09 August 2011 12:59:49 Thomas Zander wrote:
> On Monday 08 August 2011 16.28.43 Dawit A wrote:
> > > 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.
> > 
> > The uri filter plugins, which are primarly used to filter user
> > input,e.g. user typing into a konqueror's address, are time critical
> > for theobvious reasons. The architecture for these plugins relies on a
> > directsynchrounous call. See KUriFilterPlugin in
> > kio/kio/kurifilter.h.Perhaps looking at the parent of the plugin
> > classes will help clarifythe problem for you. KUriFilter loads all
> > allowed uri filter pluginsand filters the user input by invoking
> > KUriFilterPlugin::filterUri.
> 
> Ok, I understand your issue;
> 
> To me there seems to be a architectural issue which you are fighting. Might
> be interesting to keep this in mind for kde5.
> The architectural issue I'm seeing is that there is a singleton which has a
> method to filter and it blocks until the filtering is done.  This is at odds
> with the basic ingredient of using the network.
> One is blocking and can only give a result once,  but the result might get
> better if we wait a bit longer. For example with DNS lookups.
> 
> Anyway; lets make do with what we have :)
> 
> Another solution for using a timeout can be something like the attached
> version (I didn't even try to compile it, maybe the helper object has to be
> moved to a _p.h file to get moc to run on it..)
> 
> The problem that remains with this solution is that if you have 20 plusing
> that all have a timeout, your timeouts accumulate and you still get bad
> performance.  But I don't see a way to solve that using the current
> architecture.


On the patch:
By principles, Mutexes should not be hold for a long time like this. The 
proper thing to use here is a QWaitCondition