Hi sir,<br>I have patched digikam with threadweaver, i was wondering if you could give some suggestions for improving the code.<br>link to commit:<a href="https://projects.kde.org/projects/extragear/graphics/kipi-plugins/repository/revisions/844b7a49e515be936ef6fbba67047f5131b76639">https://projects.kde.org/projects/extragear/graphics/kipi-plugins/repository/revisions/844b7a49e515be936ef6fbba67047f5131b76639</a><br>
<br>Thanking You<br><br><div class="gmail_quote">On Tue, Jan 3, 2012 at 6:03 PM, Soren Harward <span dir="ltr"><<a href="mailto:stharward@gmail.com">stharward@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sun, Jan 1, 2012 at 10:56 AM, Janardhan Reddy<br>
<<a href="mailto:annapareddyjanardhanreddy@gmail.com">annapareddyjanardhanreddy@gmail.com</a>> wrote:<br>
> 1.amarok uses global static instance of threadweaver,and maximum number of<br>
> threads to be used is not specified in code anywhere if i am correct.<br>
> Does it not consume too much of cpu making the computer slow. Is there a way<br>
> to control the cpu used.<br>
<br>
</div>Amarok doesn't have any hard limits on the amount of CPU used by<br>
ThreadWeaver jobs.  Most of the uses of ThreadWeaver are for processes<br>
that are IO bound (usually because they access a network or attached<br>
device resource) and not CPU bound.  The only CPU-bound ThreadWeaver<br>
uses in Amarok are the dynamic playlist backend and the automated<br>
playlist generator (APG).  I think that the dynamic playlist is<br>
limited to a single Job, and I know (because I wrote it) that the APG<br>
is limited to one Job.  And even for both of these, the Job lasts no<br>
more than a minute on a slow machine, and is usually considerably<br>
faster.  So CPU limitations just aren't something we need to worry<br>
about most of the time.<br>
<br>
ThreadWeaver doesn't have any inherent ability to limit the amount of<br>
CPU used, other than  Weaver::setMaximumNumberOfThreads().<br>
<div class="im"><br>
> 2. Is it better to have global static instance of threadweaver or local<br>
> instances of threadweaver::weaver .<br>
<br>
</div>That depends.  Use different Weavers if you need different Weaver<br>
behavior for different types of jobs.  For example, pretend you have<br>
Job types JobA, JobB and JobC.  If you need a WeaverObserver for all<br>
JobCs, and you need to be able to cancel all JobAs at once, then it<br>
makes sense to have separate Weavers for the separate Job types.<br>
Otherwise, just stick with the global Weaver instance.  It's easier to<br>
deal with.<br>
<br>
I actually use Digikam, so if you want to put a git branch up<br>
somewhere with your ThreadWeaver work in it, I'll take a look at it.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Soren Harward<br>
_______________________________________________<br>
Amarok mailing list<br>
<a href="mailto:Amarok@kde.org">Amarok@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/amarok" target="_blank">https://mail.kde.org/mailman/listinfo/amarok</a><br>
</font></span></blockquote></div><br>