Review Request: Replace thread usage with local event loop in kio/kio/hostinfo.cpp
zander at kde.org
Mon Aug 8 20:56:24 BST 2011
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?
More information about the kde-core-devel