[gst-devel] How to solve deadlock

franchan francis.meyvis at gmail.com
Mon Nov 23 10:23:38 CET 2009


Hello,

I have a synchr. callback handling the GST_MESSAGE_BUFFERING.
It sets the playbin2 to the state GST_STATE_PAUSED.
For that content, I see that the call chain blocks like this:
gst_element_set_state()
  gst_element_set_state_func()
    GST_STATE_LOCK(elm)
      g_static_rec_mutex_lock()

Meanwhile, the test case stops the playback after 20 seconds.
For this, from the application context, the state is set to GST_STATE_NULL.
I see that that the call chain blocks like this:
gst_queue_src_active_push_pad(pad)
  gst_pad_stop_task(pad)
    GST_PAD_STREAM_LOCK(pad)
      g_static_rec_mutex_lock()

I guess I hit a deadlock (nothing happens anymore).

I think about implementing a mutex in my code around a flag indicating
'locked for buffering state-change' or 'locked for stopping state-change'
to avoid the deadlock.
I guess such a deadlock might also occur when I try to "pause"
the progressive download stream.

Is this a good solution? Or is there a better gstreamer way?

PS
Immediately after the GST_PAD_STREAM_LOCK(pad),
I see the opposite  GST_PAD_STREAM_UNLOCK(pad)
in gstpad.cc @ 5227
Might this be a left over in the code?
Or is this a check to verify a lock can be taken on the pad
before continuing doing the gst_task_join(GST_PAD_TASK(task))?




More information about the gstreamer-devel mailing list