Suspending only stopped the timer and suspended the thread weaver
queue. This is not enough: When startTimer is called the next time,
e.g. via ::addDocument, it would still trigger a call of
parseDocumentsInternal and eventually the creation of a parse job.
That one wouldn't be able to start working, as the queue is suspended.
But for clang parse jobs, it would already try to look for the
foreground parse environment (i.e. include paths and such). A future
patch will suspend the background parser while the core is being
initialized, which ensures that we won't create parse jobs with
broken environments at startup.
Details
Details
Diff Detail
Diff Detail
- Repository
- R32 KDevelop
- Lint
No Linters Available - Unit
No Unit Test Coverage
Comment Actions
Can it happen that resume() is called before ThreadWeaver has finished suspending, causing it not to resume? Otherwise LGTM