Deadlock on setting queue to NULL state in PAUSED pipeline

[Andrey Utkin]

2013/12/24 Sebastian Dröge <sebastian at centricular.com>:
> Yes, it is called immediately if the pad is idle already and otherwise
> from the pad's streaming thread as soon as it becomes idle.

BTW I see there is a race condition and plain defect:
1) with GST_PAD_PROBE_TYPE_BLOCKING, inside which i do
gst_pad_remove_probe (pad, GST_PAD_PROBE_INFO_ID (info)), is still
entered more than once;
2) in gstpad.c:1270 the return value of callback is ignored.

This is in fresh git master checkout, HEAD
b03361ac38f020bac6f06c6092adc691b3419bdf.

It is reasonable to assume that application maker should guard his
callback procedure with his own mutex, but it's pity that a feature of
return value GST_PAD_PROBE_REMOVE does not guarantee that callback
will be never more entered (i.e. there is a indeterminate delay).

You can check these issues with my sketch app
https://github.com/krieger-od/gstreamer_test
It was made up to demonstrate another problem: when probe callback is
executed from the pad thread (in my case, queue push thread), setting
that queue to NULL state (in order to properly remove the queue
element) fails. But the issue described above manifests itself in this
app, so i cannot actually debug the scenario. Any help is appreciated.

-- 
Andrey Utkin