D15959: Wait for the extraction process to finish before scheduling

Stefan BrĂ¼ns noreply at phabricator.kde.org
Fri Oct 12 20:01:51 BST 2018


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20181012/9fa05af6/attachment.html>


More information about the Kde-frameworks-devel mailing list