[Bug 674043] [0.11] Serialized allocation query deadlocks

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=674043
  GStreamer | gstreamer (core) | 0.11.x

--- Comment #3 from Wim Taymans <wim.taymans at gmail.com> 2012-04-16 09:08:23 UTC ---
(In reply to comment #2)
> I didn't mention serialized events, i meant serialized queries.

I meant serialized queries.

> 
> What if (hypothetically) there is a blocking probe that will only be removed
> when there is data coming on other pads. The data will never come though
> because qtdemux gets stuck doing the allocation query.
> 
> i.e.
> 
>            +----+---[ Pad1: thread blocked by probe 
>          / |    |           lifted when there is data on other branches]
> QtDemux +--| MQ +---[ Pad2 ]
>          \ |    |
>            +----+---[ Pad3 ]

> 
> QtDemux will do Allocation Query on pad1 from the loop thread. The thread is
> paused until Pad1 responds. However there is blocking probe on pad1 that will
> only be lifted when some other probe (on pad2 or 3) gets data, caps event etc.

You should make the probe not block on the query. Then the query will be done
(not-linked or you can reply yourself) and dataflow continues as it was before.
The fact that the query is serialized is not a problem, the new thing is that
the blocking probe and also block on queries now.

I was talking about another case where the app is waiting for no-more-pads to
remove the probes.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.