[Bug 669697] shmsink blocking forever

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=669697
  GStreamer | gst-plugins-bad | git

Vincent Penquerc'h <vincent.penquerch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vincent.penquerch at collabora
                   |                            |.co.uk

--- Comment #1 from Vincent Penquerc'h <vincent.penquerch at collabora.co.uk> 2012-02-08 21:24:28 UTC ---
This continue was added a while ago to fix an issue in a piece of software that
I cannot test anymore, so here is what I think was happening, based on my
recollection and re-reading the source for the shm plugin and GstPoll:

When a new fd is added to the poll object, a flag is set in GstPoll so that the
active_fds array is updated on next call to _wait.

Calling other GstPoll routines between adding a new fd and _wait will cause the
newly added fd to be ignored, as those routines do not check the flag and
rebuild the active_fds array.

I can't recall the reason why I chose to ensure _wait was called after adding a
new fd, instead of adding a rebuild flag check to every other _poll API. The
interesting routines (eg, _can_read) seem to be pretty fast, assuming no lock
contention, so that is an argument for not rebuilding here. The rebuilding code
does not seem to be overly slow, so I'm not sure why it's not done directly
instead of setting a flag, so causing a rebuild in every other GstPoll API
would seem to go against that caching.

A possibility for the caching might be that calling select and others on an
array of fds need that array to not change. However, calling that function is
not done inside the lock, so this doesn't seem to be the reason (bar this being
a bug).

So, a bit inconclusive on that choice. Maybe the typical use shows a lot of
modifications of the fd array compared to _wait calls, which would warrant the
rebuild delaying. I have not done such timing tests so that's just a guess.

Now, the issue here is that after the fd is added, a second call to _wait might
block, preventing the remainder of the fnuction to signal the condition
variable at the end. To fix this, I'm attaching a patch which returns on the
'continue' path if the wait would block. This is tested to fix the above
pipeline set, and has a behavior more akin to the previous code.

If it works reliably for you, I'll push this.
If someone else that knows shmsrc/shmsink can shed some light on the caching
performance reasons, please do :)

-- 
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.