[Bug 756000] gstrtmpsink: add unlock

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=756000

Håvard Graff (hgr) <havard.graff at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #312590|reviewed                    |none
             status|                            |
 Attachment #312590|0                           |1
        is obsolete|                            |

--- Comment #5 from Håvard Graff (hgr) <havard.graff at gmail.com> ---
Created attachment 324976
  --> https://bugzilla.gnome.org/attachment.cgi?id=324976&action=edit
updated patch with tests

The main problem this patch is trying to solve, is that librtmp can
poentially block a connection or a write for a very long time, potentially
stalling the application for as long as a TCP timeout can last (30 sec)

However, doing this in a MT safe way is much harder then it would appear.
The "most common" scenario would be that librtmp is currently doing
a write on the socket, and we terminate this write by using shutdown
on that internal socket. Now, had we instead used RTMP_Close, we will
often interfer with internal state inside librtmp as they are being used,
so shutdown is our only option here. We need to add a close() as well,
since the tests showed that even though we successfully cancelled one
write, while doing a handshake there can be another one as well, and
only by doing close are we preventing that second one from happening.

By also protecting the internal state with a lock, we then use _trylock
to figure out that we in fact are not allowed to touch the internal state,
but then instead use shutdown...

Finally, a looping wait is added for the case where the rtmp-lock has been
taken, but the internals of librtmp have not yet allocated the socket
it is about to work with, meaning our shutdown would fail silently, and
we would still be waiting "forever".

All of these changes are needed to make the supplied tests pass. Maybe
an atomic counter could be more elegant then using lock and trylock, but
it felt like the right solution, since we are both eliminating the
internal state completely, and when not allowed to do so, using shutdown
to break the wait.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.