RFC: Structure of background parser and language support

[Matt Rogers]

On Jul 9, 2007, at 11:08 AM, 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?
>
> Kris Wong
>

Please make this change.
--
Matt