[Bug 732866] New: udpsink blocking on g_socket_send_message()

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=732866
  GStreamer | gst-plugins-good | 1.3.90

           Summary: udpsink blocking on g_socket_send_message()
    Classification: Platform
           Product: GStreamer
           Version: 1.3.90
        OS/Version: Windows
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: jake.foytik at ipconfigure.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Problem: Testing the rtsp-server on windows using the test-launch example and
randomly connecting/disconnecting multiple streams (50) from the server. After
several iterations of connecting and disconnecting, the main loop will
occasionally enter a dead-locked state. 

I have localized the problem to when an rtsp-server class signals the "remove"
action on udpsink. The program will hang indefinitely on this function as it is
trying to obtain a lock on a mutex. It is unable to obtain the lock because the
gst_multiudpsink_render() function of gstmultiudpsink.c currently has the lock
and is stuck on the g_socket_send_message() function.

It appears I am creating some scenario where the g_socket_send_message() is
unexpectedly blocking. Reading the gsocket documentation, by default gsockets
are configured as blocking and do not have a timeout set. I couldn't find any
indication that the socket is configured (as non-blocking or with a timeout)
after its creation in udpsink or multiudpsink. Thus, using the gsocket in its
default configuration could seemingly allow the send_message() function to hang
indefinitely. Looking at gsocket.c, this could happen for one of the following
reasons:
 - The socket never indicates it it is ready for writing and the program waits
on the g_socket_condition_wait() function.
 - The WSASendTo() function repeatedly returns either a WSAEINTR or
WSAEWOULDBLOCK error, allowing the program to stay in the infinite while loop.

Since we are dealing with UDP, would it be appropriate to set the gsocket as
non-blocking and allow the send_message function to post an error?

Another option may be to have the gst_multiudpsink_remove() function trigger
the cancellable that is passed to send_message().

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