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