RFC: Structure of background parser and language support
jens at kdewebdev.org
Wed Jul 11 06:41:10 UTC 2007
On Monday 09 July 2007, 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?
The only thing that comes to my mind is that you should not assume that a
language plugin has exactly one parser to offer. In the case of Quanta we
might implement different parsers for different mimetypes we want to support.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the KDevelop-devel