D16266: [Extractor] Make extractor crash resilient

Igor Poboiko noreply at phabricator.kde.org
Wed Oct 17 11:01:58 BST 2018


poboiko added inline comments.

INLINE COMMENTS

> filecontentindexer.cpp:75
> +        bool hadErrors = false;
> +        connect(&process, &ExtractorProcess::failed, &loop, [&hadErrors, &loop]() { hadErrors = true; loop.quit(); });
> +

Is it OK to use `QObject::connect` inside a `while` loop? Those are not `Qt::UniqueConnection`, won't they fire multiple times (more and more, actually)?

> filecontentindexer.cpp:91
> +                batchSize = idList.size() / 2;
> +            }
> +            process.start();

Do I understand correctly, that's a binary-search-like way to find the file actually causing `extractor` to crash, and it will reindex some of the files in a batch ~log2(batchsize) times?
Why don't we rely instead on its progress reporting, via `startedIndexingFile` / `finishedIndexingFile`?

REPOSITORY
  R293 Baloo

REVISION DETAIL
  https://phabricator.kde.org/D16266

To: bruns, #baloo, #frameworks, poboiko, ngraham
Cc: apol, kde-frameworks-devel, ashaposhnikov, michaelh, astippich, spoorun, ngraham, bruns, abrahams
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20181017/d0d15317/attachment.html>


More information about the Kde-frameworks-devel mailing list