GStreamer-devel

Gst Locks and signals

Classic

List

Threaded

5 messages Options

Antoni Silvestre Padrós

Gst Locks and signals

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?

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Wim Taymans

Re: Gst Locks and signals

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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Antoni Silvestre Padrós

Re: Gst Locks and signals

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.

thanks,

Toni Silvestre

On Wed, Dec 22, 2010 at 11:21, Wim Taymans <[hidden email]> 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 [hidden email] 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Wim Taymans

Re: Gst Locks and signals

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 <[hidden email]>
> 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
> [hidden email]
> 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
> [hidden email]
> 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Antoni Silvestre Padrós

Re: Gst Locks and signals

Thanks a lot for such a fast fix!

Toni Silvestre

On Wed, Dec 22, 2010 at 11:48, Wim Taymans <[hidden email]> 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 <[hidden email]>
> 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
> [hidden email]
> 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
> [hidden email]
> 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 [hidden email] 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel