Does anyone ever use GST_DEBUG_FUNCPTR_NAME()?

Hi, all across the GStreamer plugins we can find GST_DEBUG_FUNCPTR being used in the class_init.

Following it’s documentation the purpose of this macro is to add a function pointer to a hash table, so the name of the function could be retrieved with GST_DEBUG_FUNCPTR_NAME.

This comes with a not critical, but still visible cost:

  1. Simplicity of the class_init function suffers, meanwhile it’s usually the most “obscure” part for the beginners.
  2. Obviously it has some micro performance cost on the application startup.

It wouldn’t be a problem if we all knew very well why GST_DEBUG_FUNCPTR is there, but to me it gives an impression of a historical artifact that have been was copied “in a sake of consistency” from one class to another without understanding the purpose.

Personally I don’t find any usecase for this feature, if the function name can be retrieved from the debugging symbols… Maybe you can corrify this statement.

What do you think?

It’s not entirely clear to me from your post whether you understand the use/utility of this stuff and just disagree with the trade-offs made or if you’re asking about the use of it - could you clarify? :slightly_smiling_face:

fair enough, so ok, utility of this stuff is not clear to me. I just follow the documentation:

GST_DEBUG_FUNCPTR
Register a pointer to a function with its name, so it can later be used by GST_DEBUG_FUNCPTR_NAME


GST_DEBUG_FUNCPTR_NAME
Retrieves the name of the function, if it was previously registered with GST_DEBUG_FUNCPTR


So I can’t imagine why would I ever need those 2. That’s why asking you, how are you using it?

Those two work in tandem.

GST_DEBUG_FUNCPTR_NAME() is something you will find used in debug log statements of base classes that call virtual methods which may have been overridden by a subclass, and other code where callback functions are installed such as GstPad.

If the subclass has registered the virtual function with GST_DEBUG_FUNCPTR, you’ll get the name of function being called in the debug log.

e.g. you might see this in the debug log output:

GST_SCHEDULING gstpad.c:4490:gst_pad_chain_data_unchecked:<streamsynchronizer0:sink_1> calling chainfunction &gst_stream_synchronizer_sink_chain with buffer buffer: 0x7ff480086a00, pts 0:00:02.043356009, dts 99:99:99.999999999, dur 0:00:00.023219955, size 8192, offset none, offset_end none, flags 0x0

Is it absolutely needed? Probably not.

Does it increase legibility of debug logs? Somewhat.

Is the performance overhead of registering these non-zero? Of course. Does it matter compared to the GObject GType machinery of instantiating a class? Doubtful, but would be interesting to see benchmarks. On the output/lookup side it’s probably negligible compared to the rest of the logging/output overhead.

Could it be done differently? Yes, but this mechanism has the advantage that it always works, on all operating systems, in all build configurations with debug logging enabled.

Are there things that could be improved? Always :slightly_smiling_face:

1 Like

It is of course quite likely that there is code where GST_DEBUG_FUNCPTR is used even though it doesn’t really make sense, e.g. where it has just been cargo-culted applied to all vfuncs regardless of whether the code calling this function will ever make use of it.

thanks for the explanation, now I see, basically it’s used in the logging of gstpad and few other classes, such as gstaudiosink.

If the subclass has registered the virtual function with GST_DEBUG_FUNCPTR , you’ll get the name of function being called in the debug log.

grepping for GST_DEBUG_FUNCPTR in the monorepo shows that of all the base classes only gstaudiosink uses it.

But if a base class doesn’t log anything with GST_DEBUG_FUNCPTR, then does it make sense to register the overrides with GST_DEBUG_FUNCPTR?

No, probably not, although perhaps logging should be added in more places :slightly_smiling_face: