[PATCH] RunnerManager

[Ryan P. Bitanga]

2008/4/21 Aaron J. Seigo <aseigo at kde.org>:
> On Monday 21 April 2008, Jordi Polo wrote:
>  > - So, user priority list and blacklist is not working (nor whitelist : the
>  > only regression I am aware about). That depends on the configuration point
>  > above. The code to implement it is there though.
>
>  yes, this is a detail at this point =)

My code will fix this :) Wait for it. Btw, the idea about the
whitelist was that if it wasn't set, all runners would be loaded,
otherwise only the whitelisted runners would be loaded. This would
render blacklisting unnecessary.

>  * the copyrights in the file are wrong. you can't copy other people's code
>  from existing files and not carry the copyright over. so there are a few
>  copyrights missing there, probably Ryan's and mine for starters.

Er, I don't think I added a copyright line. But yeah, the copyrights
should be in the runnermanager.* files. :)

I like this portion:
+int RunnerManager::launchQuery (const QString & term, const QString & runner)
+{

This would now enable us to selectively search. I think I pitched that
idea last year. Either for Katapult or for KRunner. Can't quite
remember which. But in any case I like the idea. :)

You'll find that you can manage execution a lot easier by creating new
threadweaver policies. My original policy limited executions based on
runner; there was a maximum of 3 instances of a single runner. Then I
changed it to a maximum of 3 slow runners when I realized it was still
possible for two slow runners to starve all the other runners.

IMHO we shouldn't be using heuristic algorithms for controlling the
speed or priority lists for that matter. threadweaver has a priority
queue of its own. Creating our own algorithms to work on top of that
adds complexity, resulting in longer processing time. What we should
change is the priority level of a job. threadweaver would then manage
the execution itself.

Even my concept of tiers or levels for a runner hierarchy was based on
simply modifying the priority levels and setting dependencies so that
all execution management would be handled by threadweaver.

But in any case, a RunnerManager class is way better than my initial
plan of simply dumping all my thread management classes into some
file.

Anyway, I'll go over this again within a day or two. :)

Nice work :)

Cheers,
Ryan