bruns added a comment.
In D15959#341722 <https://phabricator.kde.org/D15959#341722>, @poboiko wrote: > In D15959#339523 <https://phabricator.kde.org/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 `NewFileIndexer`s. No, this will not happen. The single entry in `m_newFiles` will essentially be moved into the the `NewFileIndexer` (Source) <https://phabricator.kde.org/source/baloo/browse/master/src/file/fileindexscheduler.cpp$97> and afterwards `m_newFiles` is `empty()`. But you are right, this should be improved. REPOSITORY R293 Baloo REVISION DETAIL https://phabricator.kde.org/D15959 To: poboiko, #baloo, #frameworks Cc: bruns, kde-frameworks-devel, ashaposhnikov, michaelh, astippich, spoorun, ngraham, abrahams
