[gst-devel] Gst Locks and signals

[Antoni Silvestre Padrós]

Thanks a lot for such a fast fix!

Toni Silvestre

On Wed, Dec 22, 2010 at 11:48, Wim Taymans <wim.taymans at gmail.com> wrote:

> 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
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20101222/38d290d1/attachment.htm>