Thread safety in GStreamer plugins

[Alexander Hedges]

Hi Tim,

Now things make a lot more sense to me. I totally missed that properties
are only supposed to be changed in the null state.
I will add the appropriate locking code to my plugin.

Best regards,
Alexander

On Mon, Mar 7, 2022 at 3:44 PM Tim-Philipp Müller <t.i.m at zen.co.uk> wrote:

> On Mon, 2022-03-07 at 13:23 +0100, Alexander Hedges via gstreamer-devel
> wrote:
>
> Hi Alexander,
>
> Short version: GStreamer elements don't really care about main loops and
> application threads, you can have as many application threads as you like,
> and you can do GStreamer things from multiple application threads if you
> must.
>
> From a GStreamer element point of view it's mostly about "streaming
> thread" vs. "other threads".
>
> For a plain filter element the streaming thread would typically be the
> thread of whichever element upstream is driving the current pipeline
> branch, e.g. a source element or parser/demuxer in pull mode or a
> queue/jitterbuffer element, for example.
>
> GStreamer elements have some locking that is taken automatically, in
> particular there is a "stream lock" on each pad that is taken automatically
> when a buffer is pushed into an element/onto a pad, or a serialized event
> (like CAPS, TAG, SEGMENT, STREAM_START, FLUSH_STOP).
>
> That automatically makes sure, for example, that an element is not going
> to reconfigure itself based on a CAPS event in a sink pad event function
> while it's at the same time processing a buffer in the same pad's chain
> function.
>
> For properties, the locking in our code base tends  a bit all over the
> place. By default element properties can only be set when the element is in
> NULL state, which means no streaming is going on and all pads are flushing
> so would just drop any data or events that  come in. Because of that, often
> there is no locking for such properties, since it's not really needed, and
> setting these properties while the element is up and running would be a
> programming error, although we don't strictly enforce that.
>
> Properties that can be changed at runtime usually have locking in place to
> make sure they're not changed while the streaming thread is using them.
>
> Hope that answers some of your questions.
>
> Cheers
>  Tim
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20220307/b383aefd/attachment.htm>