[gst-devel] Gst Locks and signals

[Wim Taymans]

On Wed, 2010-12-22 at 11:29 +0100, Antoni Silvestre Padrós wrote:
> If I haven't done anything wrong with my debugging, the
> signal request-pt-map for the GstRtpBin element is emitted with the
> element locked, and in my case my concurrent code was getting
> deadlocked in the function gst_element_get_request_pad.
> 
Ok, gstrtpsession was not releasing a lock, fixed in git with this
commit:
http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=2b53cbe923419a87df9cccd8fbcb911e61b46c9e

Wim
> 
> thanks,
> Toni Silvestre
> 
> On Wed, Dec 22, 2010 at 11:21, Wim Taymans <wim.taymans at gmail.com>
> wrote:
>         
>         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
>         
>         
>         
>         ------------------------------------------------------------------------------
>         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
> 
> 
> ------------------------------------------------------------------------------
> 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