D16266: [Extractor] Make extractor crash resilient

[Stefan Brüns]

bruns marked an inline comment as done.
bruns added inline comments.

INLINE COMMENTS

> poboiko wrote in filecontentindexer.cpp:91
> OK, we can simply count how many times we got `finishedIndexingFile`, and just go to the corresponding position in the batch.
> It's just the binary search here does look a bit unnecessary to me...

Counting would give a good hint which one failed, but still no guarantee. Files may be added or removed during the indexer run, so the position is only approximate. The indexer may also have sent a "finished" message, and crash afterwards in a destructor call.

Doing a binary search is straight forward and avoids any dependencies or assumptions about other parts of the code.

Also, this code should be only temporary anyway - if the extractor is run in a separate process which only receives the file using a readonly file descriptor (for sandboxing) and passes back the result, the problematic documents id is known by the parent process.

REPOSITORY
  R293 Baloo

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

To: bruns, #baloo, #frameworks, poboiko, ngraham
Cc: broulik, 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/20181024/73b1ec94/attachment-0001.html>