https://bugs.kde.org/show_bug.cgi?id=387238
--- Comment #4 from RJVB <rjvber...@gmail.com> --- Created attachment 109045 --> https://bugs.kde.org/attachment.cgi?id=109045&action=edit pseudo-patch to catch concurrent reloads With this in place, I see - frequent if not systematic concurrent reloads during session startup - multiple concurrent reloads running configure in an autoconf project (codeblocks) open in KDevelop (in-tree build): see the next attachment. The frequency increases when using the alternative dirwatching model which only puts watches on directories. I think the fix should be relatively trivial, along these lines: - add a new private method eventuallyStartListJob(project,item, newjob) - this method scans the current project job list *starting at the end* until it encounters a job that queues a reload for the given project item. - if a hit is found, connect that job's finished signal to the new job's start method - else, start the new job - this new method replaces all direct calls to job->start() The it might be safe to abort all jobs that have job->item()==item ; this would certainly speed up the final reload. -- You are receiving this mail because: You are watching all bug changes.
