Review Request: Enforce parse-jobs to be processed in order of their priorities

Sven Brauch svenbrauch at
Sat Feb 25 17:44:45 UTC 2012

This is an automatically generated e-mail. To reply, visit:

(Updated Feb. 25, 2012, 5:44 p.m.)

Review request for KDevelop, Milian Wolff and David Nolden.


Fix all changes proposed by milian.


As recently discussed on the mailing list, it is currently unnecessarily difficult to handle the following scenario:
File A does something like "import B"; you want A to be parsed with the top-context for B available.
Various language plugins have various solutions for this problem, but none of them were considered optimal by their creators (as far as I understood).

This patch aims to adress that problem. It changes the parsejob creation algorithm by enforcing it to wait with creating a job with a worse priority as long as jobs with a better priority are still running. Example: Three documents A, B and C are scheduled for parsing, A and B with priority 0 and C with priority -1. Assuming two parse jobs are available, the old function would create two parsejobs for C and A or B (let's say A), then wait for one of them to finish, then create a third job for B. The new function will create a parsejob for C and wait until that one is finished, and then create two jobs for A and B (still simultaneously, because they have the same priority). In other words: It's guaranteed that all parse jobs running at any specific time have the same priority. (*)

Why is that useful? Because parsejob priorities can be used to adress the above problem now: Let priority(x) be the priority of the parse-job for document x. You can then parse A, and as soon as you encounter the "import B", you can schedule B with priority(A)-1 and schedule A (again) with priority(A). That's now guaranteed to first parse B and then re-parse A with the top-context for B being available.
Oh, this patch also adds a function to get a parseJobs ownPriority(), that wasn't available before.

Please tell me what you think.

(*) I'm aware of the fact that this will decrease performance by a little bit. However, I'm pretty sure it's not relevant. If the general concept of this is accepted, I'll test it.

Diffs (updated)

  language/backgroundparser/backgroundparser.h 954ee17 
  language/backgroundparser/backgroundparser.cpp 7210254 
  language/backgroundparser/parsejob.h 135319c 
  language/backgroundparser/parsejob.cpp 552ef68 




Sven Brauch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the KDevelop-devel mailing list