[Bug 796737] ASYNC_DONE message is dropped leading to hanging application

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=796737

--- Comment #5 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
Looking closer through all this it seems like exactly one of the problems I was
looking into a long time ago. There should be another bug about it.

The problem here is already at the moment the async-start message is arriving
while we are in change_state(). It's unclear what should happen at all at that
point: it might be that change_state() triggered the message (all good then),
it might be that change_state() still has to go over that element (possibly
invalidating the message), etc. It is not clear how async-start and the
currently running state change relate to each other, if at all.

Now when async-done arrives we don't know more. It might very well be that the
async state change is now actually done, it might be that it was invalidated
(and the message we get is from before), anything really.


The underlying problem here is that we allow multiple state changes to happen
at once, and more specifically state changes from the bottom (async-start/done,
lost-state) and state changes from the top (gst_element_set_state()). I don't
think this generally leads to good results and should be prevented (and I have
ideas what to do about that in 2.0, but that's not a solution for now).

Maybe the async-start message should already have been delayed until
change_state() is done (and then any pending messages handled from there), but
I'm 100% sure that I actually wrote a patch like that and it broke other
things.

Specifically it breaks the case when the async state change was invalidated by
the change_state() (and there would never be a corresponding async-done for
example). async-start would trigger the start of an async state change that
might not even happen anymore.


I guess a potential solution (and close to my 2.0 idea) would be the following

1) queue up async-start (and async-done) if they happen during "polling"
2) If an element posted async-start and that is somehow invalidated by
change_state(), it must post async-done (I believe all elements do that
already) as part of change_state() (!)
3) After unsetting polling, check if there are pending messages. If there is an
async-start, first check if the corresponding async-done was received and if so
do nothing at all. If there is no async-done, behave as normal. If there is an
async-done without corresponding async-start, drop it.


What do you think, do you see a problem with that approach?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.