GNOME Bugzilla – Bug 638844
[PATCH] Fix pad callbacks so they handle when parent goes away
Last modified: 2011-01-10 13:15:50 UTC
Created attachment 177671 [details] [review] Patch fixing known issues of this nature in -core. 1) We need to lock and get a strong ref to the parent, if still there. 2) If it has gone away, we need to handle that gracefully. This is necessary in order to safely modify a running pipeline. Has been observed when a streaming thread is doing a buffer_alloc() while an application thread sends an event on a pad further downstream, and from within a pad probe (holding STREAM_LOCK) carries out the pipeline plumbing while the streaming thread has its buffer_alloc() in progress.
Created attachment 177673 [details] [review] Patch fixing known issues of this nature in -base RTP pay/depay base classes
Created attachment 177674 [details] [review] Patch fixing known issues of this nature in -good rtpmanager plugin
Created attachment 177675 [details] [review] Patch fixing known issues of this nature in -bad.
I've come accross the same problem and proposed the same solution. That said, I think the best solution is to change GstPad to do that for us. *** This bug has been marked as a duplicate of bug 631580 ***
(In reply to comment #4) > I've come accross the same problem and proposed the same solution. That said, I > think the best solution is to change GstPad to do that for us. > > *** This bug has been marked as a duplicate of bug 631580 *** Missed out on that bug -- thanks! The only immediate downside I can see with changing GstPad is that it would potentially result in a few extra ref/unrefs for the (few) callbacks that don't need the parent. But on the upside it would make it possible to combine the two consecutive GST_PAD_LOCK()/GST_PAD_UNLOCK()s into one. So I'm leaning towards changing GstPad to just do this for us. Thoughts, anyone?