<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=Content-Type content="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 11 (filtered medium)">  <style>  </style> </head> <body lang=EN-US link=blue vlink=purple> <div class=Section1> I noticed the GObject docs (http://library.gnome.org/devel/gobject/unstable/gobject-The-Base-Object-Type.html#GObjectClass) say:<o:p></o:p> <o:p> </o:p> Before returning, <code>dispose</code> should chain up to the <code>dispose</code> method of the parent class.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> This contradicts what I said about having GstElement provide a dispose hook for derived types.<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> So, going back to my original concern, what about simply adding the following member to GstElementClass?<o:p></o:p> <o:p> </o:p> <pre>               void       (*free_config)             (GstElement        *element);<o:p></o:p></pre> <o:p> </o:p> <o:p> </o:p> 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?<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Also, I noticed that section 23.1 of the Plugin Writer’s Guide says:<o:p></o:p> <o:p> </o:p>             Make sure the state of an element gets reset when going to <code>NULL</code>. Ideally, this should set all object properties to their original state.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Matt<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <div> <div class=MsoNormal align=center style='text-align:center'> <hr size=2 width="100%" align=center tabindex=-1> </div> From: Gruenke, Matt Sent: Monday, January 03, 2011 17:57 To: gstreamer-devel@lists.sourceforge.net Subject: GObjectClass.dispose() and GstElement<o:p></o:p> </div> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> 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().<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> 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).<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Matt<o:p></o:p> <o:p> </o:p> </div> </body> </html>