After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 609473 - [miniobject] Add support for weak references
[miniobject] Add support for weak references
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: 0.10.36
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 608702
 
 
Reported: 2010-02-09 23:37 UTC by José Alburquerque
Modified: 2011-10-29 15:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to add toggle referencing support to GstMiniObject (11.43 KB, patch)
2011-04-20 04:48 UTC, José Alburquerque
none Details | Review
Patch to add weak referencing to GstMiniObject (11.03 KB, patch)
2011-05-04 20:21 UTC, José Alburquerque
none Details | Review
Patch to add weak referencing to GstMiniObject (9.01 KB, patch)
2011-05-05 19:38 UTC, José Alburquerque
none Details | Review
Minimal test case of weak referencing (446 bytes, text/plain)
2011-05-06 16:34 UTC, José Alburquerque
  Details
Updated weak referencing patch for GstMiniObject with a unit test. (10.50 KB, patch)
2011-05-08 19:44 UTC, José Alburquerque
none Details | Review
Patch to add weak referencing to GstMiniObject with a small test (10.50 KB, patch)
2011-05-08 19:54 UTC, José Alburquerque
needs-work Details | Review
Patch to add weak referencing to GstMiniObject using instance private data (11.25 KB, patch)
2011-05-10 03:05 UTC, José Alburquerque
none Details | Review
Patch to add weak referencing functionality (11.26 KB, patch)
2011-05-10 04:43 UTC, José Alburquerque
needs-work Details | Review
Updated patch to add weak referencing to GstMiniObject using instance private data (14.89 KB, patch)
2011-05-10 18:29 UTC, José Alburquerque
needs-work Details | Review
Patch adding weak refereincing functionality to GstMiniObject (12.09 KB, patch)
2011-05-11 17:18 UTC, José Alburquerque
none Details | Review
Patch to add weak referencing to GstMiniObject (12.13 KB, patch)
2011-05-11 17:48 UTC, José Alburquerque
committed Details | Review

Description José Alburquerque 2010-02-09 23:37:41 UTC
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.
Comment 1 Sebastian Dröge (slomo) 2010-02-10 07:48:32 UTC
Adding this would be possible without breaking ABI btw, by simply putting it into instance private data and add accessor functions for them.

Also I think this is a good idea, something like GObject's toggle references and the qdata hashtables would improve the C# bindings too. I'll create a patch for that later for discussion here.
Comment 2 José Alburquerque 2010-02-12 17:51:05 UTC
(In reply to comment #1)
> Adding this would be possible without breaking ABI btw, by simply putting it
> into instance private data and add accessor functions for them.

Oh yes.  I was not aware of this, but from the GObject docs I understand.
 
> Also I think this is a good idea, something like GObject's toggle references
> and the qdata hashtables would improve the C# bindings too. I'll create a patch
> for that later for discussion here.

Great.  It will also be helpful to the C++ bindings.
Comment 3 José Alburquerque 2010-06-16 17:11:17 UTC
I know it's been a while, but I'm wondering if support for this is still planned.  Any progress?
Comment 4 Murray Cumming 2011-04-14 07:45:57 UTC
Sebastian mentioned that something like this could be added to GstMiniObject:
http://developer.gnome.org/gobject/unstable/gobject-The-Base-Object-Type.html#g-object-add-toggle-ref

It guess that would be enough for us. Right, José?
Comment 5 José Alburquerque 2011-04-14 15:53:22 UTC
Yes, that would be enough.  It would allow us to avoid the leak that presents itself when creating GstMiniObjects.
Comment 6 José Alburquerque 2011-04-14 17:23:56 UTC
I'll try to provide a patch next week.
Comment 7 Sebastian Dröge (slomo) 2011-04-14 17:30:47 UTC
Sounds great but it might make sense to implement this for 0.11 instead of 0.10, which has a completely new GstMiniObject anyway (and uses it for caps too).

But I guess you can use most of the toggleref code for both
Comment 8 José Alburquerque 2011-04-14 19:08:04 UTC
I guess there's no real rush.  I'm still willing to try a patch unless you'd rather do it yourself for 0.11.
Comment 9 José Alburquerque 2011-04-14 19:21:55 UTC
If you still feel like doing this I guess it can wait until 0.11.
Comment 10 Sebastian Dröge (slomo) 2011-04-15 08:27:54 UTC
I probably won't have time to work on this in the next days and it would be really great if you could do it... for 0.10 or 0.11 or both :)
Comment 11 José Alburquerque 2011-04-15 14:44:52 UTC
Okay.  I'll take a stab at it next week.
Comment 12 José Alburquerque 2011-04-20 04:48:09 UTC
Created attachment 186333 [details] [review]
Patch to add toggle referencing support to GstMiniObject

This patch is preliminary and can be commented on.  The code is mostly adapted from GObject but in the unreferencing I kept it as simple as it originally was (not taking into account possible re-referencing as is done in GObject), however this can be modified.  A patch for 0.11 will follow, but I thought posting this preliminary patch would be good for early review in case something should be modified before I move on to 0.11.
Comment 13 Sebastian Dröge (slomo) 2011-04-20 07:29:25 UTC
Hmm the main problem I see here is that adding a toggleref will increase the refcount by one, which makes the miniobject read-only. Thus you can never ever change a miniobject with a toggleref.

For the flag you could also use the miniobject flags btw.
Comment 14 José Alburquerque 2011-04-20 15:30:28 UTC
(In reply to comment #13)
> Hmm the main problem I see here is that adding a toggleref will increase the
> refcount by one, which makes the miniobject read-only. Thus you can never ever
> change a miniobject with a toggleref.

I keep forgetting this about mini objects.  In our case, however, we experience leaking only when taking an existing C instance and wrapping it into a C++ instance.  To do this we take an extra reference and the mini object is not writable anyway.

However, I guess looking at your initial comments about how to solve this, another solution I could provide is to allow storing data in the mini object and possibly a function facilitating the storing of data in the mini object with the option of providing destroy notification.  With or without the function (at least in 0.10), gstreamermm can use GstMiniObject's finalize mechanism to free the data.
> 
> For the flag you could also use the miniobject flags btw.

I guess.  That would mean adding a flag in the GstMiniObjectFlags enum.  I sort of quickly adapted the code from GObject and didn't stop to think too much.  I could change that if you still think the patch is worth using.
Comment 15 Sebastian Dröge (slomo) 2011-04-21 15:25:05 UTC
I talked about this with Wim yesterday and the best might be to have togglerefs that do not change the real refcount of the object. Do you see any reason why the toggleref should increase the refcount?
Comment 16 José Alburquerque 2011-04-21 16:30:48 UTC
Logically a toggle reference is an actual reference and it is possible (in GObject) to add more than one toggle reference although the docs say that in that case there will be no toggle notification until all but one toggle reference remains.  Notification occurs when the toggle reference becomes weak (ie. the toggle reference is the last reference) and also when the toggle reference becomes strong (when a new reference to the object occurs while the toggle reference is weak).

I guess with GstMiniObject it could be different in that there could be some sort of flag set when a toggle reference is added or some sort of count of toggle references which would could all be notified about the mini object having a final reference but then it would not be logically equivalent to GObject's functionality.  In that case it would have to be made clear to developers somehow.
Comment 17 Sebastian Dröge (slomo) 2011-04-26 14:02:22 UTC
What exactly would be the difference, other than that you don't automatically own a real reference? Does this make some use cases impossible?

But sure, this must be documented.
Comment 18 José Alburquerque 2011-04-26 17:24:27 UTC
(In reply to comment #17)
> What exactly would be the difference, other than that you don't automatically
> own a real reference? Does this make some use cases impossible?

Not that I can tell.  I think that functionality might be the only difference.  Suppose, for example, that several toggle references have been added and the imaginary references become weak (for all of the toggle references) so that the mini objects reference is zero (I guess).  Then during the toggle reference notification one of the callbacks wants to preserve the mini object and thus increases its reference count (would this be an actual use case?).  What happens with the rest of the callbacks waiting for notification?  Should they still be notified that the reference became weak?  What if one of the other callbacks also wants to preserve the mini object and also increases its reference?  From what I can see, it may be (in this scenario) that there might be some (endless?) recursion from a possible referencing during toggle notification (if that's allowed).

If the above use case is invalid then I think it's fine using an approach like this because all we really want is to be able to free some data when the mini object looses all its reference and this would work fine for our purposes.

> 
> But sure, this must be documented.

I can update the patch so that the documentation of the functions that add and remove toggle reference clarify this.
Comment 19 Sebastian Dröge (slomo) 2011-04-29 07:27:22 UTC
If you have multiple toggle refs on the same object the behaviour is rather weird anyway. I don't think we should allow to resurrect a mini object from the toggle ref callbacks or do you see a (useful) use case for this?
Comment 20 José Alburquerque 2011-04-29 15:15:16 UTC
Okay.  So what you're saying is that multiple toggle refs should not be allowed and allowing the resurrection of a mini object would not be practical.  That would be fine.  I just want to understand clearly to adapt the patch accordingly.  Thanks.
Comment 21 Sebastian Dröge (slomo) 2011-04-29 15:24:41 UTC
I think multiple toggle refs should be allowed, although the behaviour is a bit weird. It can always happen if you mix different languages
Comment 22 José Alburquerque 2011-04-29 16:04:54 UTC
Yes, I thought that multiple toggle references would be useful.  I guess then that not allowing for the possibility of resurrecting a mini object would mean that notification would continue normarly without fear of the notification of the toggle reference not actually being weak or strong during the notification.

I would just like to humbly say that considering the mini object writable based on it's reference is rather weird also.  For 0.11 that should be different so it doesn't impact bindings that use the reference count for purpose of just memory management (it's just humbly my opinion; BTW I think I filed a bug about this a very long time ago that could be considered for 0.11 [1]).  At any rate, I'll provide an updated patch next week.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=510301
Comment 23 Sebastian Dröge (slomo) 2011-04-29 16:10:02 UTC
(In reply to comment #22)
> Yes, I thought that multiple toggle references would be useful.  I guess then
> that not allowing for the possibility of resurrecting a mini object would mean
> that notification would continue normarly without fear of the notification of
> the toggle reference not actually being weak or strong during the notification.

Yes, let's go that road :)

> I would just like to humbly say that considering the mini object writable based
> on it's reference is rather weird also.  For 0.11 that should be different so
> it doesn't impact bindings that use the reference count for purpose of just
> memory management (it's just humbly my opinion; BTW I think I filed a bug about
> this a very long time ago that could be considered for 0.11 [1]).  At any rate,
> I'll provide an updated patch next week.
> 
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=510301

Completely agreed but unfortunately we don't have any idea yet how to separate the refcount from the writability in a sane way.
Comment 24 Wim Taymans 2011-04-29 16:12:19 UTC
(In reply to comment #22)
> I would just like to humbly say that considering the mini object writable based
> on it's reference is rather weird also.  For 0.11 that should be different so
> it doesn't impact bindings that use the reference count for purpose of just
> memory management (it's just humbly my opinion; BTW I think I filed a bug about
> this a very long time ago that could be considered for 0.11 [1]).  At any rate,
> I'll provide an updated patch next week.

In general I disagree. Making writability based on anything other than the refcount is also practically impossible or with extreme overhead. This is unlikely to be fixed in 0.11 and I would suggest to see if alternatives can be found. We can make a private pointer with a destroy notify, for example.

> 
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=510301
Comment 25 José Alburquerque 2011-04-29 16:44:27 UTC
I guess I'm looking at it from a bindings stand point and not from the overhead that it would cost, sorry.  Discussion about this should probably be done in the bug I referenced and not here anyway.
Comment 26 Sebastian Dröge (slomo) 2011-04-29 17:19:23 UTC
Note that this is a problem for bindings too, if you separate the refcount from the writability you still need to be able to guarantee that there's only one reference of the object before being able to write. Otherwise there might be multiple references in different places, one place changing the object and the other one reading a half-changed object (for example).
Comment 27 José Alburquerque 2011-04-29 19:23:50 UTC
(In reply to comment #24)
> 
> In general I disagree. Making writability based on anything other than the
> refcount is also practically impossible or with extreme overhead. This is
> unlikely to be fixed in 0.11 and I would suggest to see if alternatives can be
> found. We can make a private pointer with a destroy notify, for example.

To solve the leak problem this might be simplest avoiding the confusion that arises from the reference/writability problem we've been discussing.  I admit I'm pretty stubborn about what I perceive, but it doesn't mean I can't stop to consider other possibilities (I say this with regard to the reference/writability problem we constantly run into with the gstreamermm bindings).
Comment 28 José Alburquerque 2011-05-02 22:24:13 UTC
Another possibility is to add weak referencing/unreferencing.  These types of references are not actual references and would also provide a solution to this bug.  I could easily modify the existing patch to include the necessary functionality if desired.
Comment 29 Sebastian Dröge (slomo) 2011-05-03 07:10:16 UTC
You mean something like the weak notify stuff in GObject? Or real weak references, that just turn to NULL if the object disappears? I guess the former and that would be nice to have nonetheless if it can be implemented without adding too much overhead in the normal case when you have no weak refs.
Comment 30 José Alburquerque 2011-05-03 16:05:50 UTC
Yes, like the weak notify stuff.  Mostly, for the purposes of fixing this bug, something like g_object_weak_ref()[1], would work well.  The other related functions, of course, would also be included.  The overhead would be similar to that of toggle references and if there are no weak references, there would practically be no overhead.  I'll post a patch with the added functionality in the next couple of days so it can be reviewed.

[1] http://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html#g-object-weak-ref
Comment 31 José Alburquerque 2011-05-04 20:21:37 UTC
Created attachment 187234 [details] [review]
Patch to add weak referencing to GstMiniObject

This patch adds weak referencing to GstMiniObject.  Please review at convenience.  Thanks.
Comment 32 Sebastian Dröge (slomo) 2011-05-05 15:23:35 UTC
* Please add Since: markers to the new functions
* gst_mini_object_add_weak_pointer() is not threadsafe, same issue as in GObject and nothing that can be done about that. I don't think we want normal, non-threadsafe weak refs but only the notify variant.
* Why did you remove the toggle refs? because they're functionally the same in the previous variant?
Comment 33 José Alburquerque 2011-05-05 19:38:19 UTC
Created attachment 187315 [details] [review]
Patch to add weak referencing to GstMiniObject

Here's an updated patch with the Since: directives and removing the gst_mini_object_[add|remove]_weak_pointer() functions.  Do you still want toggle references?  I thought that this patch would be enough to fix our leaking issue. If you still want toggle references, however, that patch would still have to be updated.
Comment 34 José Alburquerque 2011-05-05 19:43:17 UTC
(In reply to comment #32)
> * Why did you remove the toggle refs? because they're functionally the same in
> the previous variant?

In essence they are almost functionally the same.  Only that toggle reference trigger notification when the reference becomes either weak or strong as opposed to what happens with weak reference notification which occurs only once when the reference becomes weak.
Comment 35 José Alburquerque 2011-05-05 19:51:52 UTC
(In reply to comment #34)
> In essence they are almost functionally the same.  Only that toggle reference
> trigger notification when the reference becomes either weak or strong as
> opposed to what happens with weak reference notification which occurs only once
> when the reference becomes weak.

But in the GstMiniObject, as was discussed (since there would be no referencing for toggle references), they may end up functionally the same, I can't be sure at the moment.
Comment 36 Sebastian Dröge (slomo) 2011-05-06 11:26:36 UTC
Could you try in gstreamermm if this would fix the problems you're seeing? Also I'm not sure I like the global mutex when adding/removing weak refs, OTOH having a mutex in every miniobject instance is not nice either. We should try to make sure that the global mutex is never touched in the normal case without any weak refs.
Comment 37 José Alburquerque 2011-05-06 16:34:26 UTC
Created attachment 187366 [details]
Minimal test case of weak referencing

Would this small test case be okay?  It runs okay for me.  This functionality would certainly allow gstreamermm to free mini object data allocated as it is finalized.  If you'd like, I can adapt the minimal test where appropriate (I think in tests/check/gst/gstminiobject.c).  Sorry about the global mutex.  It's how it's done in GObject and I see no other way of ensuring thread safety here other than using one.  As far as I can tell, it doesn't look like the mutex is used at all when there are no weak references.  Could the patch be accepted?  I could also provide a 0.11 version if desired.  Thanks.
Comment 38 Sebastian Dröge (slomo) 2011-05-07 06:38:43 UTC
Sure, a testcase like this for gstreamer/tests/check/gst/gstminiobject.c would be nice to have but I meant changes to gstreamermm that use the weak refs to do something that wasn't possible before... to make sure that this API really solves your problems.

I'll do a real review of your patch on Monday (well, maybe before). A patch for 0.11 is not really required, I'll just merge it into 0.11 after committing it to 0.10.
Comment 39 José Alburquerque 2011-05-08 19:44:40 UTC
Created attachment 187476 [details] [review]
Updated weak referencing patch for GstMiniObject with a unit test.

Okay, this updated patch adds the test.  I've also updated the gstreamermm bug that depends on this one with a patch that confirms that this patch can be used to stop the leak.
Comment 40 José Alburquerque 2011-05-08 19:54:46 UTC
Created attachment 187477 [details] [review]
Patch to add weak referencing to GstMiniObject with a small test

Updated because of a typo in a comment in gst_mini_object_class_init() (used 'toggle' instead of 'weak').  Sorry.
Comment 41 Sebastian Dröge (slomo) 2011-05-09 08:19:23 UTC
Review of attachment 187477 [details] [review]:

Looks good in general, just some minor comments and then it can IMHO be committed to 0.10... but I'd also like to wait for a second oppinion.

::: gst/gstminiobject.c
@@ +417,3 @@
+ * to stay alive).
+ *
+ * Since: 0.10.33

0.10.34

@@ +430,3 @@
+  g_return_if_fail (GST_MINI_OBJECT_REFCOUNT_VALUE (object) >= 1);
+
+  G_LOCK (weak_refs_mutex);

Instead of the mutex maybe some kind of RCU could be used here? But the mutex is fine as it's only really used when adding or removing weak refs

@@ +436,3 @@
+    wstack =
+        g_realloc (wstack,
+        sizeof (*wstack) + sizeof (wstack->weak_refs[0]) * i);

You should probably check here if the notify/data combination already exists as a weak ref

::: tests/check/gst/gstminiobject.c
@@ +183,3 @@
+on_weak_ref_notify (gpointer data, GstMiniObject * where_object_was)
+{
+  weak_ref_notify_succeeded = TRUE;

add a "fail_unless (data == (gpointer) where_object_was)" here
Comment 42 Sebastian Dröge (slomo) 2011-05-09 08:29:41 UTC
As Wim said on IRC, g_datalist_clear() and other GData API uses a global mutex. So we're using a global mutex in the miniobject finalize function now... always. This is not good and has to be changed somehow, maybe by using a different data structure. We don't need a threadsafe data structure here because everything is protected with the miniobject weak ref global mutex and finalize can only ever be called from a single thread.
Comment 43 Sebastian Dröge (slomo) 2011-05-09 08:33:31 UTC
Also please use GType instance private data in the GstMiniObject instance struct because there's only a single pointer of padding and we might want to add something else later
Comment 44 José Alburquerque 2011-05-10 03:05:21 UTC
Created attachment 187542 [details] [review]
Patch to add weak referencing to GstMiniObject using instance private data

You had mentioned using instance private data a long time ago and I completely forgot about that, sorry.  This patch uses instance private data to hold the weak references so no mutex is used during finalization.  I've also kept the global mutex for adding/removing weak references per your comments.
Comment 45 José Alburquerque 2011-05-10 04:43:01 UTC
Created attachment 187544 [details] [review]
Patch to add weak referencing functionality

Updated because while checking if the weak reference was already added I forgot to ensure that the mutex gets unlocked.
Comment 46 Sebastian Dröge (slomo) 2011-05-10 16:26:00 UTC
Looks good but please add a priv pointer to GstMiniObject, assign it in gst_mini_object_init and use that instead of always requesting the private data from gobject. The way you do it now is far too slow.
Comment 47 José Alburquerque 2011-05-10 17:28:18 UTC
I guess I'm a little confused.  Wont adding a field in GstMiniObject break ABI?  Am I wrong about that?
Comment 48 Sebastian Dröge (slomo) 2011-05-10 17:40:32 UTC
You replace the padding with the pointer to the private data
Comment 49 José Alburquerque 2011-05-10 17:52:11 UTC
I guess I was little thrown off by comment #43.  While I'm at it, are you sure it's necessary to check that a weak reference has not been previously added?  It's not done in GObject and I wasn't sure about doing it differently here.
Comment 50 José Alburquerque 2011-05-10 18:29:40 UTC
Created attachment 187593 [details] [review]
Updated patch to add weak referencing to GstMiniObject using instance private data

Nevermind.  The code already checks for duplicate weak references and that wont make a difference for fixing the bug that this bug blocks.  This patch saves the private data in the GstMiniObject structure as requested.  I hope it's okay for committing when possible.  Thanks.
Comment 51 Sebastian Dröge (slomo) 2011-05-11 08:15:06 UTC
Review of attachment 187593 [details] [review]:

Just some new comments, other than that it's good now :)

::: gst/gstminiobject.c
@@ +338,2 @@
 static void
+weak_refs_notify (gpointer data)

Just use WeakRefStack instead of gpointer here

@@ +449,3 @@
+  object->priv->wstack->weak_refs[i].notify = notify;
+  object->priv->wstack->weak_refs[i].data = data;
+found:

Maybe a g_warning() if already found, this shouldn't really happen and can only be caused by wrong code

@@ +461,3 @@
+ * Removes a weak reference callback to a mini object.
+ *
+ * Since: 0.10.33

0.10.34 everywhere

::: gst/gstminiobject.h
@@ +48,3 @@
  * Returns: reference to cloned instance.
  */
+typedef GstMiniObject *(*GstMiniObjectCopyFunction) (const GstMiniObject * obj);

Do *not* run gst-indent on headers

@@ +158,3 @@
+    gpointer data;
+  } weak_refs[1];               /* flexible array */
+} WeakRefStack;

Don't put this into the header

@@ +164,3 @@
+{
+  WeakRefStack *wstack;
+} GstMiniObjectPrivateData;

And this neither. Put
typedef struct _GstMiniObjectPrivate GstMiniObjectPrivate;
into the header

and
struct _GstMiniObjectPrivate {
  WeakRefStack *wstack;
};

into the source file. The point of the private data is to keep it private ;)
Comment 52 José Alburquerque 2011-05-11 17:18:13 UTC
Created attachment 187645 [details] [review]
Patch adding weak refereincing functionality to GstMiniObject

Okay, this updated patch includes the changes mentioned in the last review.
Comment 53 José Alburquerque 2011-05-11 17:48:27 UTC
Created attachment 187646 [details] [review]
Patch to add weak referencing to GstMiniObject

Updated to improve the g_warning message.
Comment 54 Sebastian Dröge (slomo) 2011-05-12 07:54:32 UTC
Thanks, looks good now :)
I'll push this after release and merge it into 0.11
Comment 55 Sebastian Dröge (slomo) 2011-05-14 10:03:49 UTC
commit 116972d6eb3d7fa757017df5bcbc71cffb296681
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Thu May 12 09:55:45 2011 +0200

    miniobject: Minor cleanup of last commit

commit cf671d7b0a89b24b14028a152cde8ff8e612d84e
Author: José Alburquerque <jaalburqu@svn.gnome.org>
Date:   Wed May 11 13:09:19 2011 -0400

    miniobject: Add weak referencing functionality
    
    API: gst_mini_object_weak_ref()
    API: gst_mini_object_weak_unref()
    
    Add weak referencing functionality to GstMiniObject, which
    allows to get notifications when an mini object is destroyed
    but doesn't increase the real refcount. This is mostly
    useful for bindings.
    
    Fixes bug #609473.