GNOME Bugzilla – Bug 471232
udpsrc is blocking in gst_udpsrc_unlock_stop for win32
Last modified: 2008-05-26 10:53:34 UTC
Control socket(s)/pipe for win32 is not working properly. It's not used for win32 and when trying to clear the command queue (gst_udpsrc_unlock_stop) it will block because the pipe will block on READ_COMMAND. To reproduce this; first pause a pipeline with a udpsrc, second stop it/set it to null/ready.
Created attachment 94514 [details] [review] win32 fix for udpsrc I've tried to disable control_sock for win32. It was implemented with _pipe, but not really used. Someone should verify that I haven't broken the implementation on other platforms!
Created attachment 99928 [details] [review] Fix unblocking on Windows Make unblocking work on Windows (see #345288 for the original attempt). The bottom line is that select() can only be used with sockets, and from the same provider, on Windows. This proposed solution uses WSAEventSelect() to tell Winsock about an event object to signal, and simply just set a flag and then signal this ourselves when we want to unblock.
Created attachment 99929 [details] [review] Do WSA_CLEANUP in finalize instead of GstBaseSrc::stop() Do WSA_CLEANUP in finalize instead of GstBaseSrc::stop() to avoid bad things happening if starting again. WSA_INIT increments the reference count and WSA_CLEANUP decrements it, so not having these balanced correctly is obviously a very very bad idea.
obsoleted first patch on Ole's request.
Some extra notes about the upstream version: - It does a select() with just the udp socket, so there's no way to unblock it. - For the control_sock fds it creates a pipe on Windows and a socketpair on non-Windows, and on Windows it doesn't set these fds to non-blocking, which the surrounding logic assumes they are. To make matters worse there's no way you could use select() with an AF_INET socket and a pipe, they don't share the same namespace (unlike most sane OSes).
It would be nice to see this abstracted into a separate source file, because we'll run into this problem elsewhere.
any chance this patch can be merged into GstPoll now?
Sorry for the delay on this one, our internal GStreamer branches were a couple of months behind and required a massive effort to manually quilt all the changes. Just got GstPoll to build on Windows, not yet working but it's getting there.
I believe this is now obsolete because of GstPoll.