[gst-devel] Gst Locks and signals

Wim Taymans wim.taymans at gmail.com
Wed Dec 22 11:21:03 CET 2010


On Wed, 2010-12-22 at 10:32 +0100, Antoni Silvestre Padrós wrote:
> Hi, I am using GstRtpBin for my application and I have a problem with
> signals and locks. I need the program to hold back the emission of
> certain gstrtpbin signals while I am executing some functions.
> Stopping the execution of the callbacks of those signals when they
> have already been called doesn't work because when those callbacks
> have been called the gstrtpbin code that has emitted them has already
> acquired the lock for the gstrtpbin object and my concurrent part of
> the code uses functions like gst_element_get_request_pad that also
> need to acquire that same lock.
> 
> 
> One solution would be to acquire the lock of the gstrtpbin object
> myself every time I run that part of the code that is not compatible
> with the signals. That would hold back the emission of gstrtpbin
> signals, however as gst object locks are not recursive when I use
> functions like gst_element_get_request_pad that also acquire the gst
> lock, my code gets deadlocked by locking the same mutex two times by
> the same thread. One workaround would be releasing the gst object lock
> just before any call to such functions but then obviously I would have
> the risk of a signal emission occurring in between the lock release
> and the call to the gst function that requires a lock.
> 
> 
> Right now I can't think of any elegant solution to this problem,
> anyone has any ideas? 

What are you trying to do? all signals are emitted without any locks, if
not that's a bug. What signals are you talking about, what actions are
you performing that causes deadlocks?

Wim

> 
> 
> Thanks,
> Toni Silvestre
> ------------------------------------------------------------------------------
> Forrester recently released a report on the Return on Investment (ROI) of
> Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even
> within 7 months.  Over 3 million businesses have gone Google with Google Apps:
> an online email calendar, and document program that's accessible from your 
> browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew
> _______________________________________________ gstreamer-devel mailing list gstreamer-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gstreamer-devel






More information about the gstreamer-devel mailing list