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
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Comment Actions
Can it happen that resume() is called before ThreadWeaver has finished suspending, causing it not to resume? Otherwise LGTM