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 109808 - [threads] gst_scheduler_factory_create() doesn't reference the passed element
[threads] gst_scheduler_factory_create() doesn't reference the passed element
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other other
: Normal normal
: 0.6.x
Assigned To: David Schleef
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2003-04-02 19:46 UTC by Martin Schulze
Modified: 2005-01-29 17:07 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Martin Schulze 2003-04-02 19:46:42 UTC
gst_scheduler_factory_create() uses:

  GST_ELEMENT_SCHED (parent) = sched;

to set the scheduler of the passed element. I think it should use:

  gst_element_set_scheduler(sched)

instead so that sched "gets" referenced by the "parent" element. Or should
it read: 

  gst_scheduler_add_element(sched, parent)

?

I can commit the fix myself. Just let me know.
Comment 1 Martin Schulze 2003-04-02 20:05:17 UTC
On the other hand, "parent" probably can't be referenced. (Otherwise
we would get a circular reference.) So "parent" must be set to NULL
when the "parent" element is destroyed. This would have to be done
from gst_element_dispose() or from gst_scheduler_remove_element().
Comment 2 Christian Fredrik Kalager Schaller 2003-05-12 14:19:52 UTC
Wim, what is your opinion on this?
Comment 3 Thomas Vander Stichele 2004-02-11 18:07:47 UTC
david, any ideas ?
Comment 4 Thomas Vander Stichele 2004-08-12 08:47:09 UTC
wim, david, ping ?
Comment 5 Wim Taymans 2004-12-13 11:59:25 UTC
The parent of the scheduler is the object owning the scheduler, a manager bin
like a thread or a pipeline. After adding elements to the manager bin, the
scheduler is set to the element, using GST_ELEMENT_SCHED(), and the element is
added to the scheduler using gst_scheduler_add_element(). Policies for these
operations is not very well defined though.
Comment 6 Ronald Bultje 2005-01-29 17:07:23 UTC
So all this is already done in the code. That means that the bug is long-fixed
already? This is crystal-clear to me: the parent element (thread, pipeline)
holds a reference to the scheduler, the *only* reference. The scheduler is owned
by that element, and destroyed as the element is destroyed (which happens in
gst_element_dispose). This is all already done.

The parent is obviously not referenced because circular references mean the
object never gets destroyed. Besides, the scheduler never exists without its
parent (since the parent holds reference) so that's no issue. Doesn't that meant
he bug is fixed? Please reopen if this is wrong. Marking as INVALID for now.

(Yes, I'm cleaning up bugzilla.)