From: Olivier C. <oli...@co...> - 2009-02-27 05:02:28
|
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 oli...@co... Collabora Ltd |
From: Arnout V. <ar...@mi...> - 2009-03-02 11:42:04
|
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 |
From: Wim T. <wim...@gm...> - 2009-03-02 17:26:10
|
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 gst...@li... https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |