[gst-devel] GStreamer status, 20 Sept 2005

Stefan Kost ensonic at hora-obscura.de
Wed Sep 21 01:03:54 CEST 2005

Hi David,

David Schleef wrote:
> On Tue, Sep 20, 2005 at 04:44:52PM +0200, Andy Wingo wrote:
>>In other changes, Stefan Kost checked in a patch to use GLib 2.8's
>>atomic refcounting for GObject, which was something Wim pushed hard for
>>in GLib's last development cycle. Of course, we still support the hacks
>>that allow GStreamer to work reliably with GLib as old as 2.4, but you
>>have to be careful when getting an object from GLib, as with
> I don't see much advantage to having two possible code paths here.
> There really isn't a speed advantage, and all referencing/unreffing
> must still go through gst_object_[un]ref(), so there's no API
> advantage.
Why must someone use gst_object_Ref()/unref() on a glib-2.8 system. I GstObjects 
are g_objects then refcounting is done via g_objec_ref()/unref(). There aren't 
virtual methods we can override. If GstObject behaves different then we better 
not derive from GObject.

>  It almost seems to me to be inviting someone to write
> a sloppy gstreamer-based app that works with glib-2.8, but fails/leaks
> on <= 2.6.
It does already now. Example my class has a GST_TYPE_BIN property.
Right now I need to do:

bt_song_get_property ----------------
case SONG_BIN:
   g_value_set_object(value, self->priv->bin);
#ifndef HAVE_GLIB_2_8

bt_song_set_property -----------------
case SONG_BIN:
#ifndef HAVE_GLIB_2_8
   GST_DEBUG("set the bin for the song: %p",self->priv->bin);

Otherwise the above code breaks, as g_object does not know about the ref-count 
hack and as GstObject is a GObject it treats it so.

Maybe all we need is


More information about the gstreamer-devel mailing list