RFC: Structure of background parser and language support

[Andreas Pakulat]

On 09.07.07 12:08:43, Kris Wong wrote:
> Presently, each language support has its own background parser, which
> has its own thread weaver, rather than there being only one background
> parser that serves all languages.  What we end up with is x * y number
> of background parsing threads (where x is the number of languages that
> are loaded and y is the specified number of threads per language) rather
> than just y number of parsing threads.  This seems non-intuitive to me.
> I'd like to make one background parser instance on Core that will use
> the appropriate language(s) for creating parse jobs instead of having
> each language determing if it should parse a file and adding it to its
> own background parser.
> 
> Ultimately, when a project is loaded, we would iterate through the files
> in the project and do the following:
> 
> 1. Check if there are any languages loaded that support the files MIME
> type.  If not, load the appropriate language support plugins.
> 2. Check if a duchain exists for the file in our database (if we decide
> to go this route; hasn't been designed yet).  If not parse it, otherwise
> check the timestamp and last modified date on disk to determine if the
> file needs to be re-parsed.
> 3. If the file needs to be parsed, add it to the background parser,
> which will then create a parse job for each language that supports the
> file's MIME type.
> 
> Thoughts on this?  Anything I might not have considered?

Maybe this is expected, but opening real projects is a PITA after your
changes. The walking of the project filelist and adding documents to the
parser happens in the GUI thread, which means the GUI is frozen for
about 2 minutes on kdevelop. 

Is that really supposed to happen?

Andreas

-- 
You will soon meet a person who will play an important role in your life.