Element set_property MT safety

[Roland Elek]

Hi,

Is there a well known solution to make the set_property function of a
1-to-1 filter element MT safe? By MT safe, I mean set_property itself,
and mutual exclusion with the chain function.

Is it a good idea to lock the set_property function and the chain
function with the same (new) GMutex?
Also, the chain function is already protected in gst_pad_push () by the
PAD_STREAM_LOCK of its pad. Where in general should the PAD_STREAM_LOCK
be held? If the element is 1-to-1, taking it in the set_property
function does seem to solve the problem with MT safety, but is it a good
thing to do?

Thank you in advance.

Regards,
Roland Elek
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[David Schleef-2]

On Mon, Aug 29, 2011 at 11:27:52PM +0200, Roland Elek wrote:

> Hi,
>
> Is there a well known solution to make the set_property function of
> a 1-to-1 filter element MT safe? By MT safe, I mean set_property
> itself, and mutual exclusion with the chain function.
>
> Is it a good idea to lock the set_property function and the chain
> function with the same (new) GMutex?
> Also, the chain function is already protected in gst_pad_push () by
> the PAD_STREAM_LOCK of its pad. Where in general should the
> PAD_STREAM_LOCK be held? If the element is 1-to-1, taking it in the
> set_property function does seem to solve the problem with MT safety,
> but is it a good thing to do?

Use GST_OBJECT_LOCK() and GST_OBJECT_UNLOCK(), as used to protect
object properties in most elements in gst-plugins-base, e.g.,
videoscale.



David

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel