Created attachment 373714 [details] [review]
gst_element_add_pad: remove inactive pad g_warning

The documentation incorrectly used to state that the pads were
not automatically activated when added, whereas we actually do
that when appropriate.

Callers of gst_element_add_pad must not hold the object lock,
which implies that they cannot perform the same checks as
add_pad in a non-racy manner.

This updates the documentation, and removes the g_warning
that was output before performing automatic activation.

Created attachment 373715 [details] [review]
element: remove inactive pad g_warning in add_pad

The documentation incorrectly used to state that the pads were
not automatically activated when added, whereas we actually do
that when appropriate.

Callers of gst_element_add_pad must not hold the object lock,
which implies that they cannot perform the same checks as
add_pad in a non-racy manner.

This updates the documentation, and removes the g_warning
that was output before performing automatic activation.

Review of attachment 373714 [details] [review]:

obsolete

Makes sense but I'm a bit worried about potential deadlocks caused by having gst_element_add_pad() directly activating the pad... but then it already did that before, just with a warning :)

(In reply to Sebastian Dröge (slomo) from comment #4)
> Makes sense but I'm a bit worried about potential deadlocks caused by having
> gst_element_add_pad() directly activating the pad... but then it already did
> that before, just with a warning :)

Should we push it then? :)

I think so, if nobody complains until Monday :) I think it's the right thing to do as the requirement of the current code can't possibly be implemented in a thread-safe way

Attachment 373715 [details] pushed as 2fee579 - element: remove inactive pad g_warning in add_pad