<table><tr><td style="">rjvbb created this revision.<br />Restricted Application added a subscriber: kdevelop-devel.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D9006" rel="noreferrer">View Revision</a></tr></table><br /><div><strong>REVISION SUMMARY</strong><div><p>This is a bit more proper presentation of the pseudo-patch presented in <a href="https://bugs.kde.org/show_bug.cgi?id=387238" class="remarkup-link" target="_blank" rel="noreferrer">https://bugs.kde.org/show_bug.cgi?id=387238</a> "concurrent project directory reloading".</p>

<p>Probably not very useful in the current code base so I'm not expecting this to be upstreamed or to get much constructive feedback (so don't feel obliged).<br />
Which is why I'm lumping 2 related things in the same patch:</p>

<ol class="remarkup-list">
<li class="remarkup-list-item">prevent the CPU cost and possible other side-effects of frequent project reloads (leading to concurrent FileManagerListJobs); see #387238 for discussion when this can happen.</li>
</ol>

<ol class="remarkup-list" start="2">
<li class="remarkup-list-item">represent FileManagerListJobs in the runController. This uses a proxy KJob derative so the runController can take control over its management.</li>
</ol>

<ol class="remarkup-list">
<li class="remarkup-list-item">is, I think, *a* proper way to compress reload requests. It cancels reloads queued or already running for the target directory or one of its subdirs and adds a cool-off delay before jobs are actually started (so they won't have used any CPU if overridden soon enough after having been scheduled).</li>
</ol>

<p>There may be better implementations, this one is least-change and has the advantage that everything continues to work when there are only sporadic reload requests.</p>

<ol class="remarkup-list" start="2">
<li class="remarkup-list-item">was mostly a fun hack of a feature I've been missing and that now shows me why KDevelop is sometimes not as responsive as it might be. Other than that it's probably as useful as showing unnamed and/or unkillable jobs in the runController.</li>
</ol></div></div><br /><div><strong>TEST PLAN</strong><div><ol class="remarkup-list">
<li class="remarkup-list-item">does exactly what I hoped for tested while running configure on a bigger in-tree build project like CodeBlocks with KDevelop configured to monitor directories for and reload them in case of changes. Not profiled formally, the effect is clear from following CPU usage in top, from fan noise, and from the runController buttons not turning on in the toolbar.</li>
</ol>

<ol class="remarkup-list" start="2">
<li class="remarkup-list-item">tested on Mac and Linux. Works as expected except for the fact that the initial project load puts TWO entries in the "stop individual job" dropdown menu. There are no duplicate proxies as far as  can tell so this escapes me still.</li>
</ol></div></div><br /><div><strong>REPOSITORY</strong><div><div>R32 KDevelop</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D9006" rel="noreferrer">https://phabricator.kde.org/D9006</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>kdevplatform/project/abstractfilemanagerplugin.cpp<br />
kdevplatform/project/filemanagerlistjob.cpp<br />
kdevplatform/project/filemanagerlistjob.h</div></div></div><br /><div><strong>To: </strong>rjvbb<br /><strong>Cc: </strong>kdevelop-devel<br /></div>