Thread safety in GStreamer plugins
t.i.m at zen.co.uk
Mon Mar 7 14:44:54 UTC 2022
On Mon, 2022-03-07 at 13:23 +0100, Alexander Hedges via gstreamer-devel
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
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
Hope that answers some of your questions.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gstreamer-devel