[gst-devel] [gst-cvs] ensonic gstreamer: gstreamer/ gstreamer/libs/gst/base/

Andy Wingo wingo at pobox.com
Thu Dec 27 20:17:01 CET 2007


On Tue 18 Dec 2007 04:50, Michael Smith <msmith at fluendo.com> writes:

>> > 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
> ok/safe?

Wim, you there? I'd be interested in the answer as well.



More information about the gstreamer-devel mailing list