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