Why do we call gst_object_unref() ?
Locked
Why do we call gst_object_unref() ?
 
|
This post was updated on .
CONTENTS DELETED
The author has deleted this message.
|
Re: Why do we call gst_object_unref() ?
|
|
It's used to perform
reference counting. Each use or user of an object should be counted.
When that count goes to 0, then it means the object is no longer needed and the
resources it occupies can be reclaimed. If you see an object being unref'd
that should continue to exist, then you should check up on who is resposible for
keeping a count on it, after the unref in question.
The reason this is necessary during program
execution is that numerous short-lived objects are created. If these are
never deallocated, then a program's memory usage would continually grow.
Ref-counting is sometimes described as a lesser form of garbage collection, and
is commonly used in cases where there's not necessarilly a clear relationship
between consumers and producers of objects. Be warned that ref counting
fails in the case of circular references (weak refs can sometimes be used to
avoid these scenarios).
BTW, this is complicated by the concept of
"parenting", where exclusive ownership of an object is asserted. I
encourage you to look for details about all of this in the GLib docs, as I'm
sure it must be described in there at length.
Matt
From: gst_call_me_newbie() [mailto:[hidden email]] Sent: Sun 1/2/2011 1:43 AM To: [hidden email] Subject: [gst-devel] Why do we call gst_object_unref() ? hi all, ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Why do we call gst_object_unref() ?
|
|
In reply to this post by gst_call_me_newbie()
On 02/01/11 06:43, gst_call_me_newbie() wrote:
> I checked the meaning of the function gst_object_unref() and got what it > does but I could not get why do we call it while the program is in > execution. > > for e.g this is a code snippet from the application developer manual > provided at the gstreamer's site. > > [some code here.....] > bus = gst_pipeline_get_bus (GST_PIPELINE (pipeline)); > gst_bus_add_watch (bus, my_bus_callback, loop); > gst_object_unref (bus); > [some other code here.....] > > so why would someone want to unref the bus when we still need it in our > program. If I unref it and if somehow that would have been the last > reference to the object than object would surely be destroyed. > so why should I call it. Please enlighten me. Presumably the get functions such as gst_pipeline_get_bus() automatically add a reference to each object they return, so when the object is no longer needed in the context that requested it you have to unref it. ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Why do we call gst_object_unref() ?
Administrator
|
I'm going to give you a slightly different view of this answer. This explanation is slightly less correct, but once i figured it out, the whole unref stuff made more sense. This is a simple approach and there are probably dozens of special cases I am skipping over.
First, let's say you have a program running in a local (your) thread. You want to do some Gstreamer stuff, so you create the pipeline, elements, etc. by calling gst_init() and various "create" routines. Here's the stricky part; whatever you create will not be in your local thread, It will be in some other thread (probably) spawned by the gst-Init() call. Think of this as saying your code remains "over here" and the pipeline, bus, loop, etc, are created "over there". The "create" functions return pointers that tell you not where your creations are located, but where they are described. They point at structures (located in "over there's heap) that holds the details about the pipeline or whatever you created. These structures have a refcount var in them that is set to 1 meaning somebody (you) are using those structures and the stuff they describe. Useful Note: When a pipeline is created, it creates a bus. The bus is an object "over there" but you have no idea where! A GstBus structure is also created to describe the bus itself and to hold the refcount for the bus. It is set to one showing the pipeline holds a ref to the bus. Hold that thought and see the example below. When you want to access something "over there" you must use the pointer you got from the create function or get a new pointer by asking "over there" to create a pointer/structure for you. When you are done with something, some object, "over there', you must dereference it. We do this with the g_object_unerf() function, which reduces the refcount by 1. It is possible for something to have many references. When the reference count goes to zero, the structure and the object it describes are garbage collected. Example: In your local code you create a GstBus* pointer. When you call bus = gst_pipeline_get_bus(), the pointer to the structure describing the bus is returned.. Note that, in this case, the structure doesn't have to be created. It already exists. It will be the same one created when the pipeline created the bus. It will hold a refcount of 2, one for you and one for the pipeline. Now, do whatever you need to with the bus over there, say, assign it a callback routine for the on_pad_added signal. Notice what you are really doing. You are NOT directly touching the bus. Gst_bus_add_watch() uses the information in the "bus" structure and does its magic indirectly. You set the callback pointer into the bus object itself, not its descriptive structure. finally, you need to unref the bus. You no longer need to know anything about the bus. It knows what you wanted it to know. So, use g_object_unref() to remove one ref from the structure. The refcount will decrease by one and will now equal one, the ref held by the pipeline. Had the refcount gone to zero, the bus and structure would have been garbage collected and gone out of scope. The ref held by the pipeline keeps them "alive". At the end of your program. deref-ing the pipeline will cause it to deref the bus automatically. This can be messy and confusing. Be sure to read the description of every g_ and gst_ call you make to see if it tells you to unref something. Hope this helps, Wes |
Re: Why do we call gst_object_unref() ?
|
|
Agreed about the point of always checking the docs. It occurred to me
that I should have mentioned this. Not only must you always check whether the caller is responsible for unreffing an object returned by a function, but note that some functions cause ownership or refcount transfer of objects passed as parameters. Therefore, don't forget to check what the docs say about each parameter, in addition to the return types. Over time, you'll start to notice some patterns. For instance, macros - which are in ALL_CAPS - tend not to affect refcounts or ownership. BTW, parenting is only valid for objects derived from GObject. There's another baseclass in use, called GstMiniObject. These are used for lighter-weight objects where refcounting is still desirable, like buffers. Not only can these not be parented (or weak ref'd), but they also must be unref'd using a function specific to that type (e.g. gst_buffer_unref()), rather than gst_object_unref(). Matt -----Original Message----- From: Wes Miller [mailto:[hidden email]] Sent: Monday, January 03, 2011 13:40 To: [hidden email] Subject: Re: [gst-devel] Why do we call gst_object_unref() ? <snip/> This can be messy and confusing. Be sure to read the description of every g_ and gst_ call you make to see if it tells you to unref something. <snip> ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |