Problem with pad blocking

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with pad blocking

Olivier Crête-2
Hello,

I have a case with pad blocking that I can't seem to be able to get out
of.

I have a pipeline like A->B->C where I want to change B. So I block A's
sink pad  with gst_pad_set_blocked_async(pad, TRUE, callback) and in the
callback I do {stuff(); pad_set_blocked_async(pad, FALSE,
do_nothing_callback);}..

The race I see is that another thread manages to do
gst_pad_set_blocked_async(pad, TRUE, callback) after I unblocked it
inside the callback, but before the function returns (or generally
before the PAD lock has been re-taken). So it gets in a situation where
the callback has been called, but the pad a been re-locked.. So nothing
will ever happen..

Am I missing something ?

--
Olivier Crête
[hidden email]
Collabora Ltd

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problem with pad blocking

Arnout Vandecappelle
 I don't know if it's the right thing to do, but I do the actual replacement,
including the unblocking, from the main thread.  In the block callback I just
add an idle source to the main thread.

 Regards,
 Arnout

On Friday 27 February 2009 05:38:14 Olivier Crête wrote:

> Hello,
>
> I have a case with pad blocking that I can't seem to be able to get out
> of.
>
> I have a pipeline like A->B->C where I want to change B. So I block A's
> sink pad  with gst_pad_set_blocked_async(pad, TRUE, callback) and in the
> callback I do {stuff(); pad_set_blocked_async(pad, FALSE,
> do_nothing_callback);}..
>
> The race I see is that another thread manages to do
> gst_pad_set_blocked_async(pad, TRUE, callback) after I unblocked it
> inside the callback, but before the function returns (or generally
> before the PAD lock has been re-taken). So it gets in a situation where
> the callback has been called, but the pad a been re-locked.. So nothing
> will ever happen..
>
> Am I missing something ?



--
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  D206 D44B 5155 DF98 550D  3F2A 2213 88AA A1C7 C933

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with pad blocking

Wim Taymans
In reply to this post by Olivier Crête-2
On Thu, 2009-02-26 at 23:38 -0500, Olivier Crête wrote:

> Hello,
>
> I have a case with pad blocking that I can't seem to be able to get out
> of.
>
> I have a pipeline like A->B->C where I want to change B. So I block A's
> sink pad  with gst_pad_set_blocked_async(pad, TRUE, callback) and in the
> callback I do {stuff(); pad_set_blocked_async(pad, FALSE,
> do_nothing_callback);}..
>
> The race I see is that another thread manages to do
> gst_pad_set_blocked_async(pad, TRUE, callback) after I unblocked it
> inside the callback, but before the function returns (or generally
> before the PAD lock has been re-taken). So it gets in a situation where
> the callback has been called, but the pad a been re-locked.. So nothing
> will ever happen..

I would call this a bug. We likely should keep a counter for each
block/unblock that is performed. If an unblock is followed by a block
operation, we should fire the callback again (we need the counter for
that to see that an unblock happened).

Can you file a bug?

Wim

>
> Am I missing something ?
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel


------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel