[gst-devel] requested pads

[Benjamin Otte]

On Tue, 27 Jan 2004, Andy Wingo wrote:

> On Sun, 2004-01-25 at 21:27, Benjamin Otte wrote:
> > - REQUEST pads exist as long as someone keeps a reference to it. The
> > element itself doesn't keep a reference. Normally the only reference is
> > the peer pad, so the pad goes a way when unlinking.
>
> This is, of course, not how it works. I think the way it is is the
> correct solution, as well. Under what circumstances would we want a pad
> without a parent? The whole idea is absurd except in initialization.
> Even then I'd argue that gst_pad_new (parent, name, direction) should be
> the proper incantation.
>
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.

Of course you wouldn't keep a reference to the pad yourself. Normally
every element is referenced twice: Once by their peer and once by their
parent. Request pads are only referenced by their peer. That way they go
away automatically after unlink. Unless you do it like this:
  g_object_ref (pad);
  gst_pad_unlink (pad, peerpad);
  gst_pad_link (pad, newpad);
  g_object_unref (pad);
That was what I meant with "as long as someone keeps a reference to it".

> Unless there is a compelling example of the viability of pads without
> parents, it would follow that the pad can only exist while the parent
> exists, and thus the parent should hold the sole reference on the pad,
> in all cases. (The refcounting strategy is similar to GtkTextMark in a
> GtkTextBuffer -- see the docs on this one.)
>
Pads behave exactly like GtkTextMark. They're only valid as long as
they're inside an element. However lots of code refs it to ensure
availability. Peer pads and schedulers are what comes up in my mind first.
Of course on disposal of the element, peers and schedulers release those
references :)

> 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.

Benjamin