[patch] PR28339: debuginfod groom/scan concurrency fix

[Mark Wielaard]

Hi Frank,

On Tue, 2021-09-14 at 11:20 -0400, 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 so much for finding (and fixing!) this.
It survived 3850+ cycles on my local machine. So I am hopeful this will
also work on the buildbots. Please push.

Cheers,

Mark