[Panel-devel] Multithreaded krunner

[Ryan Bitanga]

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.

Cheers,
Ryan