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