<div dir="ltr">Hi, Stefano!<br><div><div class="gmail_extra"><br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"></div><div class="gmail_quote"><span class=""></span><div>Also, stacking different "frameworks" that uses their threads in different manner, plus having a couple of static threads that are rarely used might not be the best idea.</div><div><br></div><div>Obviously "fixing" this is easier to be said than done, though since we have stroke jobs that can be concurrent, "partially concurrent", blocking etc, it can be a good reason to have a system like that, so not "blindly" hard capping threads numbers, but doing something more sophisticated.</div></div></div></div></blockquote><div><br></div><div>I'm totally agree with you about "stacking" frameworks. It is not the best option. We could experiment with it when a trivial solution is done. When we have a QtConcurrent-based solution, we can manually experiment with threads balancing. And if it shows better performance, say, more than 20%, we will improve the scheduler and processing framework. Do you like that plan? :)<br></div><div> </div></div>-- <br><div class="gmail_signature">Dmitry Kazakov</div>
</div></div></div>