"GStreamer" (GNOME Bugzilla)
2016-06-07 12:22:42 UTC
https://bugzilla.gnome.org/show_bug.cgi?id=767333
Bug ID: 767333
Summary: Uses the same thread for multiple clients and blocks
them on media preparation, leads to deadlocks
Classification: Platform
Product: GStreamer
Version: 1.8.1
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-rtsp-server
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@coaxion.net
QA Contact: gstreamer-***@lists.freedesktop.org
GNOME version: ---
Currently when a client connects, a thread is assigned to this client and
everything that happens with this client happens on that thread. By itself this
is not a problem, but unfortunately from this very thread the rtsp-media is
also waiting synchronously to be prepared.
This means that while the media is being prepared, no other client that uses
the same thread can send requests or get responses. And especially this can
lead to various deadlock situations, for example:
- two clients are connecting and creating a media (one for each) that is fed
from an appsrc
- the appsrcs are both fed from the same, other pipeline
- the first client finishes preparing the media (-> the pipeline is blocked)
- the second client starts preparing the media
- the other pipeline is blocking because the first appsrc is blocked
- the second appsrc never gets enough data to preroll, and the first appsrc is
never unblocked because the client has no way to send its PLAY request to
unblock the pipeline
We should wait asynchronously for the media to be prepared, which unfortunately
requires a few changes in the way how rtsp-client.c works. Currently
request-response is a completely synchronous process.
Bug ID: 767333
Summary: Uses the same thread for multiple clients and blocks
them on media preparation, leads to deadlocks
Classification: Platform
Product: GStreamer
Version: 1.8.1
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-rtsp-server
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@coaxion.net
QA Contact: gstreamer-***@lists.freedesktop.org
GNOME version: ---
Currently when a client connects, a thread is assigned to this client and
everything that happens with this client happens on that thread. By itself this
is not a problem, but unfortunately from this very thread the rtsp-media is
also waiting synchronously to be prepared.
This means that while the media is being prepared, no other client that uses
the same thread can send requests or get responses. And especially this can
lead to various deadlock situations, for example:
- two clients are connecting and creating a media (one for each) that is fed
from an appsrc
- the appsrcs are both fed from the same, other pipeline
- the first client finishes preparing the media (-> the pipeline is blocked)
- the second client starts preparing the media
- the other pipeline is blocking because the first appsrc is blocked
- the second appsrc never gets enough data to preroll, and the first appsrc is
never unblocked because the client has no way to send its PLAY request to
unblock the pipeline
We should wait asynchronously for the media to be prepared, which unfortunately
requires a few changes in the way how rtsp-client.c works. Currently
request-response is a completely synchronous process.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.