Bug #8259
openlib: examples fail with debug validation as they create threads after threads are sealed
Description
The Suricata "custom" lib example initializes ThreadVars after calling, SuricataInit, it does this as it initializes them as close as possible to creating the threads.
However, SuricataInit "seals" the threads and adds a debug validation. This fix is for:
- library users to setup their own custom run modes with RunModeRegisterNewRunMode and register a callback
- create the ThreadVars in this callback (optionally the threads could be created here as well)
- SuricataInit then runs this callback
- After SuricataInit, but before SuricataPostInit, the actual threads can be created, or the create ThreadVars could be injected into exist threads, etc.
This is all backportable to 8. However in main we can also remove:
RunModeRegisterNewRunMode(RUNMODE_LIB, "offline", ...); RunModeRegisterNewRunMode(RUNMODE_LIB, "live", ...);
in runmode-lib.c, and force users to go through the custom runmode registration, which probably makes more sense anyways, at least with the current threading design.
Documentation should be updated to recommend this approach to users of the 8.o library.
Updated by OISF Ticketbot about 4 hours ago
- Label deleted (
Needs backport to 8.0)