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

[Sven Brauch]

> On Feb. 25, 2012, 5:57 p.m., Milian Wolff wrote:
> > small stuff, but then it looks fine I think.
> > 
> > I'd like to get one last heads-up from david though, esp. in regard to the bool done & break change.
> > 
> > cheers

Yes, I'd also like to hear from david first. Maybe it breaks something which nobody of us noticed :)
I didn't update the patch now for those two chars, hope that's okay.


> On Feb. 25, 2012, 5:57 p.m., Milian Wolff wrote:
> > language/backgroundparser/backgroundparser.cpp, line 345
> > <http://git.reviewboard.kde.org/r/104019/diff/8/?file=51127#file51127line345>
> >
> >     still wrap the foreach body in {} please

Okay -- I usually do, I just did it that way because the other two surrounding functions did it too. I now changed it for all three of them.


> On Feb. 25, 2012, 5:57 p.m., Milian Wolff wrote:
> > language/backgroundparser/parsejob.h, line 115
> > <http://git.reviewboard.kde.org/r/104019/diff/8/?file=51128#file51128line115>
> >
> >     no need for const here

okay, but -- why?


- Sven


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104019/#review10896
-----------------------------------------------------------


On Feb. 25, 2012, 5:48 p.m., Sven Brauch wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104019/
> -----------------------------------------------------------
> 
> (Updated Feb. 25, 2012, 5:48 p.m.)
> 
> 
> Review request for KDevelop, Milian Wolff and David Nolden.
> 
> 
> Description
> -------
> 
> 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.
> 
> Greetings,
> Sven
> ________
> (*) 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
> -----
> 
>   language/backgroundparser/backgroundparser.h 954ee17 
>   language/backgroundparser/backgroundparser.cpp 7210254 
>   language/backgroundparser/parsejob.h 135319c 
>   language/backgroundparser/parsejob.cpp 552ef68 
> 
> Diff: http://git.reviewboard.kde.org/r/104019/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Sven Brauch
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120226/37f9397e/attachment.html>