[gst-devel] [gst-cvs] ensonic gstreamer: gstreamer/ gstreamer/libs/gst/base/
msmith at fluendo.com
Tue Dec 18 10:50:41 CET 2007
> > gst_pad_get_parent() takes the object lock. You've replaced it with code
> > that does not take the object lock, and is not called with the object
> > lock taken.
> > Please explain or revert. I think reversion is needed.
> It was discussed on IRC. gst_pad_get_parent() does not take any lock as far as I
> see. If it does those should also be released. And reffing the pad that one own
> already is not required. You will find that e.g. elements already use the macros
> (e.g. gst_queue_loop()). Its not consistet though. Feel free to apply it elsewhere.
As I said, gst_pad_get_parent() takes the pad object lock. It then refs
the _parent_, not the pad (you're correct, of course, that reffing the
pad again isn't needed - it doesn't do that).
Perhaps Wim can clarify - what cases require gst_pad_get_parent(), and
where is it safe to only use GST_PAD_PARENT()? Is Stefan's patch
More information about the gstreamer-devel