Information Needed on use of thread weaver in amarok

Janardhan Reddy annapareddyjanardhanreddy at gmail.com
Sun Feb 12 06:46:16 UTC 2012


Hi sir,
I have patched digikam with threadweaver, i was wondering if you could give
some suggestions for improving the code.
link to commit:
https://projects.kde.org/projects/extragear/graphics/kipi-plugins/repository/revisions/844b7a49e515be936ef6fbba67047f5131b76639

Thanking You

On Tue, Jan 3, 2012 at 6:03 PM, Soren Harward <stharward at gmail.com> wrote:

> 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
> _______________________________________________
> Amarok mailing list
> Amarok at kde.org
> https://mail.kde.org/mailman/listinfo/amarok
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok/attachments/20120212/c399817b/attachment.html>


More information about the Amarok mailing list