Add tracing activity and tracing section API
The new barectf_is_tracing_enabled() function allows the instrumented
program to enable or disable tracing for a specific barectf context.
This is a thread-safe API, in that it only sets a member of the context
to 0 or 1. Disabling the tracing activity does not guarantee, however,
that the current packet or back-end is not currently being altered. See
the next paragraph about this.
The new barectf_is_in_tracing_section() function allows the instrumented
program to know if its tracing thread is currently in a barectf section
or not. barectf_is_in_tracing_section_ptr() returns a volatile pointer
to this same information.
Both functions can be used together to implement a snapshot action for a
given platform, something like:
1. The instrumented thread calls the barectf tracing functions during
its execution. When a packet is closed, the platform appends it to a
ring buffer, overwriting the oldest recorded one if there's no space
left. This is called a flight recorder mode.
2. The controller (another thread of the instrumented program, or an
external host) recognizes a trigger where we would only need the
latest data to analyze the situation. Therefore tracing must be
stopped, because we don't want the current ring buffer packets to be
overwritten anymore.
3. The controller disables tracing. It is safe to call
barectf_is_tracing_enabled(ctx, 0) from another thread.
4. When barectf_is_tracing_enabled(ctx, 0) is called, the barectf
tracing function currently being executed still needs to finish. At
this point it could still alter the current packet. Therefore the
controller waits until barectf_is_in_tracing_section() is 0.
5. Once barectf_is_in_tracing_section() returns 0, it won't return 1
until barectf_is_tracing_enabled(ctx, 1) is called again, so it is
safe to read the ring buffer, and also to read the current packet.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
This page took 0.0248 seconds and 4 git commands to generate.