Introduce thread-safe handling for complaints
authorTom Tromey <tom@tromey.com>
Mon, 6 Sep 2021 16:20:02 +0000 (10:20 -0600)
committerTom Tromey <tom@tromey.com>
Tue, 12 Apr 2022 15:31:16 +0000 (09:31 -0600)
commitda6322977928bc23b0d6a3a88af8c935fb334f3e
tree3278ff13c47423791dee79084776db84a57afbed
parent68a85bc267a7ecbcbe3a465bd80aac60b3b70d5a
Introduce thread-safe handling for complaints

This introduces a new class that can be used to make the "complaint"
code thread-safe.  Instantiating the class installs a new handler that
collects complaints, and then prints them all when the object is
destroyed.

This approach requires some locks.  I couldn't think of a better way
to handle this, though, because the I/O system is not thread-safe.

It seemed to me that only GDB developers are likely to enable
complaints, and because the complaint macro handle this case already
(before any locks are required), I reasoned that any performance
degradation that would result here would be fine.

As an aside about complaints -- are they useful at all?  I just ignore
them, myself, since mostly they seem to indicate compiler problems
that can't be solved in the GDB world anyway.  I'd personally prefer
them to be in a separate tool, like a hypothetical 'dwarflint'.
gdb/complaints.c
gdb/complaints.h