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 <f...@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 <f...@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
