GNOME Bugzilla – Bug 695702
gst_poll_wait never return even if gst_poll_set_flushing true
Last modified: 2016-06-22 14:51:35 UTC
in case we use ppoll in linux implementation of gst_poll_wait and all fd in the set->active_fds->data are inacticve (ie there are no readable or writable data) and we remove all elements from the active_fds then gst_poll_wait never return which cause a deadlock in the user apps. this can happened (eg in case of tcpserversink when the source element in the pipeline before the sink do not always send data) that the gst_poll_wait never return even after all client disconnected and it's try to remove all fd from the clients set. even if we try to restart with gst_poll_restart but we're not bale to interrupt gst_poll_wait since it's wait in the ppoll call. the solution would be if can return from the ppoll without write or read, but as ppoll called with NULL as the last argument, we currently can't send any kind of signal to the ppoll since can't get the thread id of the ppoll thread. is there any solution to this deadlock?
we can abour with USR1 singal (if we patch gstreamer): http://stackoverflow.com/questions/4048886/abort-linux-polling but we not able to send it to the right thread.
Can you provide a testcase for this? If I understand the problem correctly another solution for this would be to always have an additional fd in the set that is only used for waking up the poll if no other fd is left anymore.
yesss! we don't think about this hack, but we like this simple solution:-) could you tell me how can we implement it? or even could you give us a patch to test?:-) ps. testcase is very hard. it's happened very rare and hard to catch, but it can happened for us every 1-2 hours.
do you have any tipp how can we implement it? which kind of dummy fd should have to be added? etc? any tipps are welcome:-)
GstPoll already has a dummy fd to unlock on set_flushing(TRUE).. I'd be really curious to see a simple test case also.
What's up with this? Is this still a problem with 1.6? My understanding is that this should already work and we don't actually know what the problem is?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!