[Panel-devel] Multithreaded krunner
Ryan Bitanga
ephebiphobic at gmail.com
Thu Nov 22 10:55:36 CET 2007
> >
> > Changes I snuck in:
> > - change canBeConfigured() to isConfigurable() for the sake of API
> > consistency
>
> looks good. this part should be committed regardless.
>
Committed the whitelist and the cosmetic change to canBeConfigured.
> > - KRunner may not be responsive if the query is changed while the
> > match method of a slow runner is being executed by threadweaver.
> > This is because ThreadWeaver doesn't abort jobs that are currently
> > being run and aborting jobs requires the implementers of runners to
> > have knowledge about ThreadWeaver jobs.
>
> hm... how much and what kind of knowledge? because this probably isn't worth
> doing unless we can make the UI completely fluid.
>
Should I continue looking for solutions to this? Would it be
acceptable to add a requestAbort() method and an isAborting() method
to AbstractRunner, a bool m_abort to AbstractRunner::Private, then
require placing if( isAborting() ) statements in critical parts of
match() methods?
Another solution would be for Runners to cache the query by storing it
in AbstractRunner::Private::term then pass the cached query to
addPossibleMatch(), addExactMatch(), and addInformationalMatch(). If
the query is not the same as the current query, the request can be
safely ignored. The only problem would be deleting the match.
What do you think?
Cheers,
Ryan
More information about the Panel-devel
mailing list