[PATCH] RunnerManager

[Jordi Polo]

On Tue, Apr 22, 2008 at 10:16 PM, Ryan P. Bitanga <ryan.bitanga at gmail.com>
wrote:

> 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.
>

In fact what I thought was 2 lists:

- priority list
- black list

As proposed by Aseigo, two constructors can be made, one of them with a
kconfiggroup object.
If the object is used, the application can have its own configuration and
hence its own priority or black listing.
Else the application uses global priority set by the user.
Any runner not in the priority list just no user priority boost

I prefer black list over white list because:

- With a lot of runners (We all hope for this) it will be easier to explicit
what you don't want and, ok, main reason is because is funnier destroy
saying what you don't want and see how your not wanted results die :P

- When a new runner is installed by an third party app, it doesn't need to
touch every configuration file's white list to add itself. It will not in
the priority list, so no priority boost but at least will display its
results with no extra configuration.





> >  * 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. :)


Yes, you are not either in interface or abstractrunner classes (where I
stole the code from) . I've already added you.


>
>
> 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.


Threadweaver has a queue of jobs. AFAIK, if no dependences are given between
the jobs are given, it will process the jobs in a FIFO fashion.
Thinking about it, it appears to me as a more difficult problem as it may
seem.
If runners is ordered and add them to the job queue as they appear in the
list, . results of faster runners will appear first. Setting dependencies is
tricky also, as we will have several concurrent threads but the user will
likely provide a ordered list, comply with that and having concurrent
processing is difficult ... Priority won't help when one runner is order of
times slower than other ...

So, why not worry very little about runners (just have the list ordered and
launch them in FIFO) and worry about ordering the results?

That's my ugly double foreach loop in the matches() method that orders only
when the app request the matches. If the loop is ugly (aseigo already didn't
like it) it can be change that to inserting the result in the correct
position each time a match is added to the context.
I wait for your comments before doing that.
Expect a remade patch later today.

As a side note, I guess I will pretty much cut much of my krunner
development time in the short future. I applied to GSoC but failed. Meaning
I should look for a job ASAP and living in Japan, a job means 10-14
hours/day 6days/week. No much free time left.





>
>
> 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
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>



-- 
Jordi Polo Carres
NLP laboratory - NAIST
http://www.bahasara.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20080422/482ba322/attachment-0001.html