[Tracking] Make the plugin table API compatible with multithreading for built in tables #2802
Description
Currently, the plugin table API implementation for built-in tables tightly couples the underlying type, e.g. a SS_PLUGIN_ST_UINT64 can only be stored in an actual uint64_t. This prevents us from using e.g. atomic integers as table fields. Given that we expose a lot of fields in the thread and fd tables, we're effectively blocked from any form of safe concurrent access.
The series this issue tracks aims to fix that and make the built in table implementation more flexible, while keeping performance no worse than the current implementation (in my tests, I got up to 5% speedup).
Please note that this series does not introduce any sort of concurrency support into the table API, it just removes a blocker that we'd run into sooner or later with just about any attempt at multithreaded state access.
Related: falcosecurity/falco#3749
The whole series can be seen in #2804 (which is admittedly large and hard to review but can give you the bigger picture).
PR links will appear here as I submit them.
- cleanup(libsinsp): minor cleanups in the built in table implementation #2803
- fix(build): fix build warnings with clang #2808
- fix(build): disable clang/ASAN check for offsetof hack #2818
- cleanup(libsinsp): push down table methods into the table classes #2807
- cleanup(libsinsp): collapse static_struct and dynamic_struct into extensible_struct #2835
- cleanup(libsinsp): use {read,write}_field #2843
- cleanup(libsinsp): remove sinsp_field_accessor_wrapper #2846
- cleanup(libsinsp): untangle table/entry class hierarchy #2848