[gstreamer-bugs] [Bug 609473] New: It would be nice if GstMiniObject derived classes supported storing data for bindings

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=609473
  GStreamer | gstreamer (core) | git

           Summary: It would be nice if GstMiniObject derived classes
                    supported storing data for bindings
    Classification: Desktop
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: jaalburqu at svn.gnome.org
         QAContact: gstreamer-bugs at lists.sourceforge.net
      GNOME target: ---
     GNOME version: ---


Hi.  gstreamermm is experiencing a leak of wrapper objects created on the fly
for instances of GstMiniObject and its derived classes (GstMessage, etc.).  The
reason for this is that the mechanism in place for producing and finally
removing wrappers in gstreamermm (and other *mm libraries) is mostly designed
for GObject derived classes which support storing data in the C instance which
can later be retrieved and deleted on notification of destruction of the
GObject.

GstMiniObject is similar to GObject but it doesn't support storing data that
can later be retrieved in the C instance.  It does have a finalize virtual
function thereby allowing for the possibility of knowing that a miniobject is
about to be destroyed, but unfortunately there's no way of storing a wrapper in
the C instance.

I'm sure this is not something that can resolved quickly, but the reason I'm
filing it is that the gstreamermm leak has been reported and I'm having a hard
time fixing it:

https://bugzilla.gnome.org/show_bug.cgi?id=608702

What I'm proposing, if possible, is at least a gpointer member variable (maybe
called "bindings_data"?) in the instances of the GstMiniObject derived classes
(or in the GstMiniObject instance itself) in which to store "arbitrary" data. 
The data can then be retrieved when the miniobject is finalized and freed so
there's no leak.

An optional additional feature could be that there would be a function (or
functions) with which to set the data accepting a GDestroyNotify function which
would be called when the miniobject is finalized.

I know this can't be solved without considering ABI implications so by no means
do I expect this to be solved quickly or easily, but if ABI considerations are
approved, I'm pretty sure I can provide a pretty usable patch after that for
this if it is approved.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.