[Panel-devel] Multithreaded krunner

[Ryan Bitanga]

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.

Cheers,
Ryan