I've actually redone and removed a couple of the timers that were originally from Alpha, mostly because there is now a JobQueue that performs some lengtly operations and when that operation is done, the result is, when a lot of UI events come in, often no longer desired and is therefore dropped.Hi, yvesdm3000, thanks for the reply. You said that old events may be dropped when they are not desired, that's the same thing I said, great! I will look at your git code repo to see how JobQueue works in your clangCC.
You must however keep in mind that most of the Clang-operations are not read-only (sadly not even the code-completion operation since it does a simplified reparse) so they cannot be parallelized.What do you mean by "not read-only", you mean you can not call two functions inside the clang shared library at the same time from two worker thread?
You can parallelize on different translation units, but generally we're only interested in 1 translation unit: The one we're editing. Experiments using 2 translation units for the same document showed that Clang doesn't like it, and we can't copy a translation unit. So we're stuck with 1 JobQueue (except for indexing, could be totally separated because there is no interaction with the UI needed so ThreadPool comes to mind)Do you means you have one JobQueue for one translation unit?
I currently designed it so to keep lock contention to a minimum by sending a message to the one job queue and sending a message back for event handling but also for destruction purposes.Does the JobQueue works on a worker thread?
Patches and/or suggestions for improvements on ClangCC are always welcome. :-)OK, if I can build the ClangCC plugin, and test it. ;)
Hi, yvesdm3000, thanks for the reply. You said that old events may be dropped when they are not desired, that's the same thing I said, great! I will look at your git code repo to see how JobQueue works in your clangCC.An example is probably better here:
What do you mean by "not read-only", you mean you can not call two functions inside the clang shared library at the same time from two worker thread?When things are read-only (and const), you could read from it from multiple threads. This is not at all applicable here as I explained.
Do you means you have one JobQueue for one translation unit?No reason to have a JobQueue for one translation unit. It would only help when you switch from one document to another and I don't consider that a problem at all currently.
Under the native CC, we have one ThreadPool running a lot of parser threads to index all the files inside a cbp project.I'll probably have the same once the indexing code of ALL files is in place, but I start with 1 thread to keep development simple and move to a ThreadPool later.
Does the JobQueue works on a worker thread?I suggest using the one from the 'staging' branch, it's nearly ready to be merged into master, only a double diagnostics-event needs to be fixed in it, which is not too shaby.
[/quote/
Yes. It's the C::B implementation.QuoteQuotePatches and/or suggestions for improvements on ClangCC are always welcome. :-)OK, if I can build the ClangCC plugin, and test it. ;)
I haven't used clang code completion for several years, I see the last time I use clangCC was around 2011, at that time, I use the git repo https://github.com/Lalaland/ClangComplete.git (https://github.com/Lalaland/ClangComplete.git), but I see this project is halt around 2012.
ClangCodeCompletion m_CodeCompletion;
ClangDiagnostics m_Diagnostics;
ClangToolbar m_Toolbar;
But I haven't see some code that you can drop some already queued job from the thread queue. So, maybe, I need to implement one...