[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-devel
Subject:    RFC: Structure of background parser and language support
From:       "Kris Wong" <wongk () seapine ! com>
Date:       2007-07-09 16:08:43
Message-ID: D1EF2A02037CA74CBC1C6AF3F5E0F7310236E6B5 () ex3 ! seapine ! com
[Download RAW message or body]

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

_______________________________________________
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]