[Panel-devel] Multithreaded krunner

[Aaron J. Seigo]

On Monday 03 December 2007, Ryan Bitanga wrote:
> On Dec 3, 2007 11:48 AM, Ryan Bitanga <ephebiphobic at gmail.com> wrote:
> > On 12/3/07, Aaron J. Seigo <aseigo at kde.org> wrote:
> > > > Apparently, the "continue running match method and discard matches
> > > > when outdated" approach has the problem of allowing slow runners to
> > > > hog the CPU while not doing anything useful. It appears our choice
> > > > are: 1) add provisions for aborting within some runners as I
> > > > explained in an earlier e-mail,
> > >
> > > yes, this probably makes sense for extermely slow runners. as the
> > > number of runners grows, this will be more of a problem, of course. one
> > > thing that occurred to me is instead of reissuing a search every 200ms,
> > > to be a bit smarter about when we issue new match attempts based on the
> > > text input and how many matches are currently runnng; we may even want
> > > to split runners into different groups ("hot path", "useful",
> > > "epxensive" ... ?) and stagger their runs. this is something we can
> > > research further over time.
> >
> > I think I may have found a solution. I could write a queue policy that
> > prevents more than (max number of threads - 1) jobs for the same
> > runner from being executed at the same time. This would have a worst
> > case performance of behaving like a single-threaded application. I'm
> > not exactly sure this is possible because I'm not sure if I can check
> > the type of the queued job within the queue policy. I'll investigate
> > in a few hours. Splitting runners into groups would require authors of
> > runners to know the relative speed of their runner. We could provide
> > an enum in AbstractRunner and then set the type within the constructor
> > of the runner. If someone got to work on an algorithm we could see if
> > it significantly improves responsiveness. I don't have the time at the
> > moment, but if no one else works on it, maybe I can develop one within
> > the next few weeks.
>
> Committed the queue policy. Note: it doesn't completely solve the
> problem. If more than one runner dominates the CPU, i.e. if another
> slow runner with an outdated search term is being executed, no results
> will be produced. The long term solution would be to introduce an enum
> in AbstractionRunner, say, enum RunnerSpeed { NormalSpeed = 0,
> SlowSpeed }, methods speed() and setSpeed(speed) and then use the
> speed to group runners in the queue policy instead of the runner name.
> Of course someone could think of better names, but you get the idea.

yep; i think it's in good enough shape right now that we can safely do this 
for 4.0.x or 4.1.x though; don't worry about missing more class/study time 
for it unless you actually want to ;)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20071203/592a19aa/attachment.pgp