[gst-devel] GObjectClass.dispose() and GstElement

[Gruenke, Matt]

I noticed the GObject docs
(http://library.gnome.org/devel/gobject/unstable/gobject-The-Base-Object
-Type.html#GObjectClass) say:

 

Before returning, dispose should chain up to the dispose method of the
parent class.

 

 

This contradicts what I said about having GstElement provide a dispose
hook for derived types.

 

The descriptions of GObjectClass.dispose() and GObjectClass.finalize()
make it unclear where deallocation of property values should happen, but
I'd imagine it would be fine to do this from dispose().  I'm guessing
that the clause "client method invocations still work" after dispose()
refers mostly to GObject methods and "still work" simply means no
segfaults.

 

So, going back to my original concern, what about simply adding the
following member to GstElementClass?

 

               void       (*free_config)             (GstElement
*element);

 

 

If not, then how about at least describing how to tie into
GObject.dispose(), in the Plugin Writer's Guide, and maybe adding an
example to the templates?

 

 

Also, I noticed that section 23.1 of the Plugin Writer's Guide says:

 

            Make sure the state of an element gets reset when going to
NULL. Ideally, this should set all object properties to their original
state.

 

 

Again, why not add a hook in GstElementClass to support this?  Most
people probably miss it, and it forces you to tie into state transitions
- even if you're using a pre-made baseclass whose start() and stop()
hooks seem to imply that doing so is unnecessary.

 

 

Matt

 

 

________________________________

From: Gruenke, Matt 
Sent: Monday, January 03, 2011 17:57
To: gstreamer-devel at lists.sourceforge.net
Subject: GObjectClass.dispose() and GstElement

 

Based on my reading of the Plugin Writer's Guide & the GstElement
reference docs, elements are supposed to complete all of their
deallocation on the READY -> NULL transition.  However, it's always
bothered me that there's a case where you could still get a memory leak.

 

Suppose an element's GObjectClass.set_property() gets called while the
element is still in the NULL state.  If this property accepts a string
or some other type of heap-allocated object, the element is probably
going to create a copy or add a ref.  Now, suppose some problem occurs
and the element is disposed before ever going to the READY state.  There
will be no transition back to NULL.  Therefore, the only possibility of
deallocating the value is by overriding GstObjetClass.dispose().

 

I concede that this isn't normally an issue, since the size of any such
properties is likely to be very small and many applications will either
exit or typically repeat this sequence a limited number of times.
However, it's quite possible that some sort of automated recording
application might repeat this sequence somewhat rapidly and for an
indefinite period of time.

 

Then, there's the whole philosophical issue of avoiding even small
leaks, which turns into a very practical issue when trying to use tools
to find slightly more serious leaks.  I know you can usually work around
this, through the use of filtering, but it's inconvenient and not always
satisfactory... let's please try to avoid a flame war about this.

 

Would it be so bad for GstObjectClass and GstElementClass to at least
provide a dispose() hook?  I'm aware that I could just save the old
value & replace with my own dispose(), but something feels wrong about
having the derived type dispose of its ancestors.  It's also not a very
user-friendly way to do it, since there are numerous ways the derived
type can mess things up (i.e. not saving the old value or failing to
call it last).

 

 

Matt

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20110104/bd6d3125/attachment.htm>