GNOME Bugzilla – Bug 669697
shmsink blocking forever
Last modified: 2012-02-09 18:42:27 UTC
I was trying to play with shmsink/shmsrc with the following simple gst-launch pipelines: (1) gst-launch -v videotestsrc ! shmsink socket-path=/tmp/blah shm-size=1000000 (2) gst-launch shmsrc socket-path=/tmp/blah ! "video/x-raw-yuv, format=(fourcc)YUY2, color-matrix=(string)sdtv, chroma-site=(string)mpeg2, width=(int)320, height=(int)240, framerate=(fraction)30/1" ! autovideosink pipeline (2) is launched after (1), and the caps I put are the ones I see output by the first gst-launch. Both pipelines block forever. In (2), shmsrc never seems to get any buffer (I think it never gets anything on the socket). In (1), pollthread_func() is blocked on gst_poll_wait(), after having gone through the continue added in a34108899ea5027be67e8a2c77c4ef67c093eb83. Reverting that commit fixes the issue, and both pipelines work as expected, though I don't know if that's the best solution as I don't understand the concrete issue that it solves.
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 :)
Created attachment 207141 [details] [review] shmsink: fix indefinite wait after adding a new fd to the poll set If the second call to _wait blocks, we will not signal the condition variable, so ensure that second call is not blocking. See rationale and information in the linked bug:
The patch seems to work well for my case. Thanks a lot!
Thanks for the confirmation. commit c83532553663218d7e89590afa574429bc1a3fe3 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Wed Feb 8 21:21:47 2012 +0000 shmsink: fix indefinite wait after adding a new fd to the poll set If the second call to _wait blocks, we will not signal the condition variable, so ensure that second call is not blocking. See rationale and information in the linked bug: https://bugzilla.gnome.org/show_bug.cgi?id=669697