GNOME Bugzilla – Bug 632504
[rtspsrc] reduce or avoid (network) hang during shutdown
Last modified: 2011-06-15 22:43:41 UTC
During state change to PAUSED and READY, rtspsrc sends PAUSE and TEARDOWN respectively (if server supports), which might hang (for the duration of configured tcp_timeout, default = 20s) due to network problems. Subsequent patches arrange for: * sending PAUSED (if done) in a separate (temporary) thread (i.e. asynchronously) (and if that one were to hang, it can then be interrupted by a subsequent going to READY) * a separate property that controls the timeout when performing TEARDOWN (or allows to skip TEARDOWN altogether, as it is but marginally useful to do so if immediately followed by closing connection).
Created attachment 172646 [details] [review] rtspsrc: refactor some simple message sending
Created attachment 172647 [details] [review] rtspsrc: minimize network hang during shutdown
Getting to the point of async operations in this branch: http://cgit.freedesktop.org/~wtay/gst-plugins-good/log/?h=progress
AFAICS, the async operations still perform "close stuff" going to READY, and then (synchronously) wait for this to end (or timeout) when going to NULL, so particularly a network hang during shutdown remains possible that way. Then again, it is tricky, since not waiting for completion when going to NULL would practically come down to not bothering doing anything going to READY in the first place. And not really doing "much chatter" (i.e. closing connections directly) may be the only way to avoid hang altogether. So, is it possible to integrate a shorter shutdown timeout as in the other patches' approach (or whatever would help ensuring a not-so-hanging shutdown) (and/or to use former patches until async operations polished/finished)?
Specifically, as described above, going to PAUSED (PAUSE) or to READY (TEARDOWN) are not interruptable since src->waiting is not set (in branch as described above). Following branch (extending aforementioned branch) addresses that issue as well as some other async handling fixes which IMHO should make it ready to go to master (otherwise comments welcome ;) ): http://git.collabora.co.uk/?p=user/manauw/gst-plugins-good.git;a=shortlog;h=refs/heads/progress
Branch as mentioned above pushed to master, among which following ones that particularly aim to avoid hanging at shutdown: commit dc2ddea91befb4bc38116f4e08e459f99e0b3329 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Wed Apr 6 16:05:55 2011 +0200 rtspsrc: also allow PAUSE to be interrupted ... as it is on the way out to NULL. See #632504. commit 283e4e4afdf7c5a6b2a93ee95d6b3de0aebf1120 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Wed Apr 6 15:51:49 2011 +0200 rtspsrc: ensure proper closing and cleanup ... since the TEARDOWN sequence might not have had a chance to even start, but at least connections should be closed (synchronously) and state cleaned up. See #632504. commit f7ddf811d76285229f6e0a4a5ce8cce83e1729a9 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Wed Apr 6 15:49:01 2011 +0200 rtspsrc: fix and improve async handling Simplify the command handling; passing a command to thread means we really want it to get the message, which means to always flush provided the command can handle being interrupted. Command thread indicates whether command allows interruption and ensure non-flushing connection as it subsequently needs it. In particular, this also makes the TEARDOWN sequence interruptable and also prevents races where _loop_ could miss a command and would continue receiving (or at least trying to). See #632504.