Hi,
On Tue 18 Dec 2007 04:50, Michael Smith <
[hidden email]> 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.
Cheers,
Andy
--
http://wingolog.org/-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Locked
