Deadlock on setting queue to NULL state in PAUSED pipeline

[Sebastian Dröge]

On Sa, 2013-12-21 at 12:03 +0200, Andrey Utkin wrote:
> 2013/12/21 Sebastian Dröge <sebastian at centricular.com>:
> > No, this deadlocks because the queue is still doing data-flow and when
> > setting it to READY/NULL this has to stop first. Because the pipeline is
> > PAUSED this will never happen though.
> 
> But how the flow should be stopped except setting pipeline to PAUSED
> state? Is that special for queues, or some (or all?) other elements
> need some special treating in such case?

It's the same for all elements. In PAUSED state there is data-flow, but
the clocks are not running, and as such the pads are most likely blocked
with pushing a buffer.

> > What exactly are you trying to do there?
> 
> In my real scenario, i add or remove consuming elements at random time
> after pipeline init. I set pipeline to PAUSED state before any such
> operation.
> Let's say i have a producing bin, which provides request sourcepads.
> Inside this bin, for each request pad we request a srcpad from a tee,
> link a queue after this tee srcpad, and return queue srcpad to
> consumer (proxied with bin ghostpad, of course).
> And this trouble happens when i remove the consumer: request pad gets
> released, and in request pad releasing callback i need to free the
> queue element.

Take a look at pad probes, especially the idle probe. From that probe
callback you can safely relink elements inside a pipeline, even in
PLAYING state. PAUSED state might be a bit dangerous because of what I
mentioned above (the pad might never become idle).

-- 
Sebastian Dröge, Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20131221/bf7edac4/attachment-0001.pgp>