That doesn't looks like it works all the time: sometimes I still have this issue.
Apparently, it still can happen that even when the process is finished, signal is emitted, but the thread is not finished yet.

Also, it seems like due to QueuedConnection, ExtractorProcess can get removed before signal is processed, and because of that signal got lost. We can try something like that:

connect(&process, &ExtractorProcess::finished, this, [this]{
             QMetaObject::invokeMethod(this, "done", Qt::QueuedConnection);
});

(so that finished signal is processed immediately, but the done signal is emitted queued).

I think the most trivial and completely correct way to fix this problem is to remove the m_threadPool.activeThreadCount() check from scheduleIndexing(). QThreadPool::start(runnable) puts the runnable in the run queue if there is still another thread running.

This works for me:

 void FileIndexScheduler::scheduleIndexing()
 {
-    if (m_threadPool.activeThreadCount() || m_indexerState == Suspended) {
+    if (m_indexerState == Suspended) {
         return;
     }

In D15959#339523, @bruns wrote:

This works for me:

 void FileIndexScheduler::scheduleIndexing()
 {
-    if (m_threadPool.activeThreadCount() || m_indexerState == Suspended) {
+    if (m_indexerState == Suspended) {
         return;
     }

That might require some changes in the scheduling logic. Right now it will behave weirdly.
If we do this change, there might be situations where bunch of i.e. ModifiedFileIndexer gets pushed to queue in a row. For example, we were inside FirstRunIndexer, and 10 files were modified.
Even worse, if will have a single new file and then 10 modified files - it will push 10 NewFileIndexers.

In D15959#341722, @poboiko wrote:

In D15959#339523, @bruns wrote:

This works for me:

 void FileIndexScheduler::scheduleIndexing()
 {
-    if (m_threadPool.activeThreadCount() || m_indexerState == Suspended) {
+    if (m_indexerState == Suspended) {
         return;
     }

That might require some changes in the scheduling logic. Right now it will behave weirdly.
If we do this change, there might be situations where bunch of i.e. ModifiedFileIndexer gets pushed to queue in a row. For example, we were inside FirstRunIndexer, and 10 files were modified.

Yes, this could happen ...

Even worse, if will have a single new file and then 10 modified files - it will push 10 NewFileIndexers.

No, this will not happen. The single entry in m_newFiles will essentially be moved into the the NewFileIndexer (Source) and afterwards m_newFiles is empty().

But you are right, this should be improved.