gst-python deadlock with GIL and pipeline mutex

Bruno Gonzalez (aka stenyak) stenyak at gmail.com
Thu Aug 1 01:00:17 PDT 2013


Hi,

I'm using gst-python 0.10.22 and gstreamer 0.10.36 (unfortunately, at this
time I can not upgrade to the 1.x branch). I have a python program that
creates a pipeline, in which it serves video via rtsp.

Everything works correctly if I let it stream on its own, but it can
deadlock very easily under the following situation.

Thread 1:
--------------
At the request of the rtsp client, the rtsp server may decide to change
some parameters on its pipeline elements, all while the video is PLAYING.
Part of that process involves calling:
my_pipeline.get_by_name("my_videocrop")

Internally, get_by_name() will try to temporarily acquire the
pipeline->lock mutex. This action is originated in python code, so thread 1
has the GIL while get_by_name() tries to acquire the pipeline lock.


Thread 2:
--------------
On the otherhand, during PLAYING state, a gstreamer C thread will be
calling several gst_pad_push() functions throughout the pipeline elements.

In my case, this long chain of function calls arrives at a call to:
gst_pad_set_caps()
then (after a few calls): gst_object_dispatch_properties_changed()
then (again after a few calls): gst_object_get_parent()
Inside this last function, the aforementioned pipeline->lock mutex is
succesfully acquired.
Shortly after that, pyg_toggle_notify() is called, which tries to acquire
the GIL lock in order to modify a python object reference count.


So there we have the deadlock:
 - Thread 1 already has the GIL, and tries to acquire the pipeline lock in
order to finish get_by_name().
 - Thread 2 already has the pipeline lock, and tries to acquire the GIL in
order to Py_INCREF() or Py_DECREF().


>From what I understand, this means that get_by_name() should never be
called by python code while the pipeline is running.
Does this happen by design? I.e. should I always set the pipeline to PAUSE
or NULL before searching for its elements by name, or use some other
workaround?
Or is it a bug in my code, and Thread 2 should never need to modify any
reference count?


Any help is much appreciated. Thanks!

-- 
Regards/Saludos,
     Bruno Gonzalez

http://www.stenyak.com | stenyak @ irc://irc.freenode.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130801/6e0ead9e/attachment.html>


More information about the gstreamer-devel mailing list