RFC: Structure of background parser and language support

[Jens Herden]

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. 

Jens
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20070711/e260d742/attachment.sig>