[Panel-devel] Multithreaded krunner

Ryan Bitanga ephebiphobic at gmail.com
Sun Nov 18 15:11:10 CET 2007


> and SearchAction is there because QAction is GUI and therefore not thread
> safe, correct?
>
Yep.
> > Changes I snuck in:
> > - change canBeConfigured() to isConfigurable() for the sake of API
> > consistency
>
> looks good. this part should be committed regardless.
>
> > - add a whitelist to loadRunners() so users can selectively
> > load runner plug-ins in the future
>
> please commit this part; thought this:
>
>
> if( whitelist.empty() || !whitelist.empty() && whitelist.contains(
> service->name() ) )
>
> could just be:
>
> if (whitelist.isEmpty() || whitelist.contains(service->name()))
>
oops... thought i corrected that already. i don't have an SVN account
but i plan on continuing to help so i take it i should apply for one?

> > Possible problems:
> > - 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.

i'm not exactly certain how it can be done elegantly. but one option
is to place if (abort) {//cleanup code then return} clauses in
potentially computational heavy areas of the match() methods of each
runner.

the worst case performance of a multithreaded krunner is supposed to
be equal to its performance right now... and to be honest i haven't
been testing unpatched krunners so i can't really compare the
performances. but there are instances where krunner locks up for me
for a few seconds and that only happens when i abuse it (and rarely at
that)... so with normal usage i think the current solution for
multithreading used in my patch should be sufficient. But then again,
without testing on different hardware it's difficult to determine if
the implementation is acceptable already.

Cheers,
Ryan


More information about the Panel-devel mailing list