https://sourceware.org/bugzilla/show_bug.cgi?id=28339
Bug ID: 28339
Summary: groom/scan race condition
Product: elfutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: debuginfod
Assignee: fche at redhat dot com
Reporter: fche at redhat dot com
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
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.
--
You are receiving this mail because:
You are on the CC list for the bug.
