From 2d5ba30606378e1d018a77a2f9e2ca686518c495 Mon Sep 17 00:00:00 2001 From: Stefan Sauer Date: Sat, 16 Jan 2016 13:28:32 +0100 Subject: [PATCH] docs/design: update tracerspec examples --- docs/design/part-tracing.txt | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/docs/design/part-tracing.txt b/docs/design/part-tracing.txt index 6777143f0b..df98f52e4b 100644 --- a/docs/design/part-tracing.txt +++ b/docs/design/part-tracing.txt @@ -41,7 +41,7 @@ plugins: GST_TRACER_PLUGINS="log(events,buffers);stats(all)". When then plugins are loaded, we'll add them to certain hooks according to which they are interested in. -Right now tracing info is logged as GstStructures to the TRACE level. +Right now tracing info is logged as GstStructures to the TRACE level. Idea: Another env var GST_TRACE_CHANNEL could be used to send the tracing to a file or a socket. See https://bugzilla.gnome.org/show_bug.cgi?id=733188 for discussion on these environment variables. @@ -147,8 +147,8 @@ gst_structure_new ("thread-rusage.class", // 'thread-id' is a 'key' to related the record to something as indicated // by 'scope' substructure "thread-id", GST_TYPE_STRUCTURE, gst_structure_new ("scope", - // enum { process, thread, element, pad, context?, ... } - "related-to", G_TYPE_STRING, "thread", + "type", G_TYPE_GTYPE, G_TYPE_GUINT64, + "related-to", GST_TYPE_TRACER_VALUE_SCOPE, GST_TRACER_VALUE_SCOPE_THREAD, NULL), // next value in the record // 'average-cpuload' is a measurement as indicated by the 'value' @@ -162,7 +162,7 @@ gst_structure_new ("thread-rusage.class", // flags { aggregated, windowed, cumulative, ... } "flags", G_TYPE_STRING, "aggregated", // value range - "min", G_TYPE_UINT, 0, + "min", G_TYPE_UINT, 0, "max", G_TYPE_UINT, 100, NULL), ... @@ -193,11 +193,11 @@ G_TYPE_UINT64 to specify the time of the event. We could also consider to add each value as a READABLE gobject property. The property has name/description. We could use qdata for scope and flags (or have some new property flags). -We would also need a new "notify" signal, so that value-change notifications +We would also need a new "notify" signal, so that value-change notifications would include a time-stamp. This way the tracers would not needs to be aware of the logging. The core tracer would register the notify handlers and emit the log. -Or we just add a gst_tracer_class_install_event() and that mimics the +Or we just add a gst_tracer_class_install_event() and that mimics the g_object_class_install_property(). Frontends can: @@ -321,17 +321,17 @@ Problems / Open items right now the tracer hooks are defined as an enum though. - when connecting to a running app, we can't easily get the 'current' state if - logging is using a socket, as past events are not explicitly stored, we could - determine the current topology and emit events with GST_CLOCK_TIME_NONE as ts + logging is using a socket, as past events are not explicitly stored, we could + determine the current topology and emit events with GST_CLOCK_TIME_NONE as ts to indicate that the events are synthetic. -- we need stable ids for scopes (elements, pads) +- we need stable ids for scopes (threads, elements, pads) - the address can be reused - we can use gst_util_seqnum_next() - - something like gst_object_get_path_string() won't work as objects are + - something like gst_object_get_path_string() won't work as objects are initially without parent -- right now the tracing-hooks are enabled/disabled from configure with +- right now the tracing-hooks are enabled/disabled from configure with --{enable,disable}-gst-tracer-hooks The tracer code and the plugins are still built though. We should add a --{enable,disable}-gst-tracer to disabled the whole system, allthough this @@ -358,7 +358,7 @@ Performance =========== run ./tests/benchmarks/tracing.sh -egrep -c "(proc|thread)-rusage" trace.log +egrep -c "(proc|thread)-rusage" trace.log 658618 grep -c "gst_tracer_log_trace" trace.log 823351