GNOME Bugzilla – Bug 710850
gstrtspconnection: force blocking tls handshaking
Last modified: 2013-10-30 14:35:52 UTC
glib and glib-networking 2.38. Problem found while testing git version of gst-rtsp-server. The server hangs. Currently, gst_rtsp_source_dispatch_read performs all reads non-blocking. The handshaking happens implicitly in the first read and as we are non-blocking, the handshaking happens asynchronously in a separate thread. As we are handshaking g_pollable_input_stream_read_nonblocking will return G_IO_ERROR_WOULD_BLOCK. gst_rtsp_source_dispatch_read is not called anymore as the RTSP client has already send the data and is waiting for an answer.
Created attachment 258074 [details] [review] block first read and force synchrnous handshaking in TLS connection Couldn't find any other way to solve this easily. So here's the first try. From the source code comment: /** * If we have a TLS connection, we are doing implicit auto-handshaking * (which happens in a separate thread) when we first call the read * functions in fill_raw_bytes. If we use non-blocking read here, we * would get a G_IO_ERROR_TIMED_OUT during handshaking and we would * just exit the dispatch read. So, we want the implicit * auto-handshaking to happen synchronously. */
Sorry guys. This is clearly not the way to properly fix this problem. Even this bad hack fixes the problem, I think the code should work as it is now. The problem is that something bad happens when the pollable input stream returns G_IO_WOULD_WORK. It does it twice, but the source dispatch function is not called again. Right now, I don't think there's nothing rtspconnection can do. I will mark this as invalid.