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