diff options
author | Tom Tromey <tom@tromey.com> | 2021-09-06 10:20:02 -0600 |
---|---|---|
committer | Tom Tromey <tom@tromey.com> | 2022-04-12 09:31:16 -0600 |
commit | da6322977928bc23b0d6a3a88af8c935fb334f3e (patch) | |
tree | 3278ff13c47423791dee79084776db84a57afbed /gdb/c-lang.c | |
parent | 68a85bc267a7ecbcbe3a465bd80aac60b3b70d5a (diff) | |
download | gdb-da6322977928bc23b0d6a3a88af8c935fb334f3e.zip gdb-da6322977928bc23b0d6a3a88af8c935fb334f3e.tar.gz gdb-da6322977928bc23b0d6a3a88af8c935fb334f3e.tar.bz2 |
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'.
Diffstat (limited to 'gdb/c-lang.c')
0 files changed, 0 insertions, 0 deletions