Re: [patch] PR28339: debuginfod groom/scan concurrency fix

[Magne Hov <mhov@undo.io>]

Hi Frank,

On Tue, Sep 14 2021, Frank Ch. Eigler via Elfutils-devel wrote:

> commit ce695bedf073127883bbbaab528dd1f2b0e955f1 (HEAD -> master)
> Author: Frank Ch. Eigler <fche@redhat.com>
> Date:   Tue Sep 14 08:15:23 2021 -0400
>
>     PR28339: debuginfod: fix groom/scan race condition on just-emptied queue
>     
>     debuginfod's scan and groom operations (thread_main_scanner,
>     thread_main_fts_source_paths) are intended to be mutually exclusive,
>     as a substitute for more complicated sql transaction batching.  (This
>     is because scanning / grooming involves inserting or deleting data
>     from multiple related tables.)
>     
>     The workq class that governs this in debuginfod.cxx has a problem: if
>     the workq just becomes empty, its sole entry pulled by a scanner
>     thread in response to a wait_front(), an 'idler' groomer thread is
>     ALSO permitted to run, because there is no indication as to when the
>     scanner thread operation finishes, only when it starts.
>     
>     Extending the workq with a counter ("fronters") to track any active
>     scanning activity (even if the workq is empty) lets us block idlers
>     groomers a little longer.
>     
>     Signed-off-by: Frank Ch. Eigler <fche@redhat.com>

Thanks a lot for this fix. We've had an issue in automated testing where
`nuke orphan buildids` is executed after `rpm-buildid-intern` has run
but *before* `rpm-de-insert` has run. The result is missing BUILDIDS for
the archive, and rescans of the archive fail to re-add them because the
archive is registered as already having been scanned.

I think this fix will resovle this.