Project

General

Profile

Actions

Bug #8259

open

lib: examples fail with debug validation as they create threads after threads are sealed

Added by Jason Ish about 6 hours ago. Updated about 6 hours ago.

Status:
In Progress
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

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.


Subtasks 1 (1 open0 closed)

Bug #8260: lib: examples fail with debug validation as they create threads after threads are sealed (8.0.x backport)AssignedJason IshActions
Actions

Also available in: Atom PDF