[gst-devel] requested pads

[Andy Wingo]

Howdy Benjamin,

On Sat, 2004-01-31 at 11:30, Benjamin Otte wrote:
> The important part for me is this: If I have a link and unlink it, I want
> the request pads to automatically go away. Being forced to check if srcpad
> or sinkpad are request pads and then manually call a function to remove
> them seems quite bad to me.

Oh yes, I agree: if you don't call gst_element_get_request_pad, you
shouldn't have to release it. But see the end of this mail.

> Request pads are only referenced by their peer.

I think you are incorrect here. The parent of a request pad is an
element (set in gst_element_add_pad). gst_object_set_parent refs the
pad.

> > That's how I see it anyway. I could be wrong. But special-casing
> > reference counting for request pads is sure to cause problems later.
> > It's difficult enough to "prove" anything will work in GStreamer, and
> > this would complicate matters. Let's punt the responsibility to the
> > calling code, where (IMO) it belongs.
> >
> The calling code never even knows if there is a request pad when it did
> gst_element_link (a, b) so it doesn't know if it needs to release any of
> them. There might be other examples where request pads are created
> implicitly.

In this case, the calling code is actually gst_element_link (or whatever
subroutine requests the pad). It's not all that complicated. Whatever
code requests a pad must release it. If the calling code is actually
libgstreamer, libgstreamer connects to the ::unlink signal to do the
cleanup work.

Sound sane?
-- 
Andy Wingo <wingo at pobox.com>