Information Needed on use of thread weaver in amarok

[Soren Harward]

On Sun, Jan 1, 2012 at 10:56 AM, Janardhan Reddy
<annapareddyjanardhanreddy at gmail.com> wrote:
> 1.amarok uses global static instance of threadweaver,and maximum number of
> threads to be used is not specified in code anywhere if i am correct.
> Does it not consume too much of cpu making the computer slow. Is there a way
> to control the cpu used.

Amarok doesn't have any hard limits on the amount of CPU used by
ThreadWeaver jobs.  Most of the uses of ThreadWeaver are for processes
that are IO bound (usually because they access a network or attached
device resource) and not CPU bound.  The only CPU-bound ThreadWeaver
uses in Amarok are the dynamic playlist backend and the automated
playlist generator (APG).  I think that the dynamic playlist is
limited to a single Job, and I know (because I wrote it) that the APG
is limited to one Job.  And even for both of these, the Job lasts no
more than a minute on a slow machine, and is usually considerably
faster.  So CPU limitations just aren't something we need to worry
about most of the time.

ThreadWeaver doesn't have any inherent ability to limit the amount of
CPU used, other than  Weaver::setMaximumNumberOfThreads().

> 2. Is it better to have global static instance of threadweaver or local
> instances of threadweaver::weaver .

That depends.  Use different Weavers if you need different Weaver
behavior for different types of jobs.  For example, pretend you have
Job types JobA, JobB and JobC.  If you need a WeaverObserver for all
JobCs, and you need to be able to cancel all JobAs at once, then it
makes sense to have separate Weavers for the separate Job types.
Otherwise, just stick with the global Weaver instance.  It's easier to
deal with.

I actually use Digikam, so if you want to put a git branch up
somewhere with your ThreadWeaver work in it, I'll take a look at it.

-- 
Soren Harward