https://bugs.kde.org/show_bug.cgi?id=387238

RJVB <rjvber...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #109045|0                           |1
        is obsolete|                            |
 Attachment #109046|0                           |1
        is obsolete|                            |

--- Comment #6 from RJVB <rjvber...@gmail.com> ---
Created attachment 109056
  --> https://bugs.kde.org/attachment.cgi?id=109056&action=edit
pseudo patch

My previous patch had a glaring error and gave off false alarms. It is probably
unlikely that dirwatching ever leads to concurrent reloads with the current
dirwatching model, but that model is inappropriate as argued (and IIRC agreed
upon) in #384880 .

Using (sub)directory-only dirwatching to implement project/disk sync means
every on-disk change will be relayed to the project manager as a
KDirWatch::dirty signal for the enclosing directory, triggering a reload of
that directory.

There is a CPU cost to the consequence (running multiple KIO jobs; the cost is
evident in terms of fan noise in larger projects and shows up as 100% CPU
presumably of the main thread). Projects using in-tree builds will thus see
competition for CPU cycles for a convenience feature with more crucial features
like configuring, compiling and showing the output of such processes.

More importantly: how robust is the project model itself against changes in the
same directory being fed in from multiple background directory reloads?

The updated pseudo-patch above explores a few ideas to limit those effects. For
each new FileManagerListJob for a given directory, the current project job list
is scanned and
- jobs started to reload the same directory are aborted and removed from the
joblist
- the directory is unqueued from jobs that have it queued 
- async jobs are started with a small delay so that most are never actually
started when the reload requests come in too rapidly. (NB: this doesn't affect
the initial load nor reloads requested explicitly via the UI.)

I'll be running this patch in my own fork and I'll welcome constructive
feedback.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to