Handling of a server request is racy, and the connection can get
flushed if the app sends a
SET_PARAMETER request to the server while
handle-request signal handler is running. This will cause the
response to never get sent out, and the server will have to timeout
even though it successfully sent the request to us.
This is because
gst_rtspsrc_loop_send_cmd() first cancels the
currently-pending command, then checks
src->busy_cmd to check whether
it is allowed to flush the connection and interrupt the currently-running command, but we don't
update that when handling a request, so the connection gets flushed.
We also cannot update
src->busy_cmd for handle_request because that
can only be safely written to from one location:
src->task, which is thread-safe due to how
Reads are thread-safe due to the object lock, but writes from multiple
threads aren't thread-safe even with the object lock because the
command specified in
busy_cmd is not executed with the object lock
held, so we'd need to hold the object lock while executing
handle_request, and we might as well not update
busy_cmd at all.