[Bug 750728] New: Stream deadlocks on Windows

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 750728
           Summary: Stream deadlocks on Windows
    Classification: Platform
           Product: GStreamer
           Version: 1.4.5
                OS: Windows
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-rtsp-server
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: jake.foytik at ipconfigure.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Problem: On Windows, when serving streams from rtsp-server I am frequently
observing the streams lockup (stop transmitting data on the server side). The
problem seems to occur more frequently if the server is under network load.

I have traced the issue to multiudpsink's call to g_socket_send_message().
Further, it appears to be a race condition in gsocket that causes the
WSAWaitForMultipleEvents() function to be called just after the WSAEvent
structure has been cleared, resulting in an infinite wait for an FD_WRITE
signal that has already occurred. 

Looking at rtsp-stream.c a gsocket is created and given to a udpsrc element and
also given to a multiudpsink element. Does this mean that multiple threads are
reading and writing to the same socket and is this safe? (refer to
https://bugzilla.gnome.org/show_bug.cgi?id=705027) 

My tests/debugging at the gsocket level indicates that multiple threads are
accessing the same socket for reading and writing which is causing the issue on
Windows.

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