[gst-devel] Problem with pad blocking

Wim Taymans wim.taymans at gmail.com
Mon Mar 2 18:28:32 CET 2009


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 gstreamer-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gstreamer-devel





More information about the gstreamer-devel mailing list