[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