mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-12-31 20:48:56 +00:00
4d514abfd6
When receiving an sctp message for a stream that not yet has an sctpdec pad associated with it means we end up in _on_sctpdec_pad_added. At this point we're holding the sctpassocation lock. Then it's not possible to take the pc_lock because then code executing under the pc_lock (which means anything in the webrtc thread) may not take the sctpassociation lock. For example, running the data channel close procedure from the webrtc thread means we eventually end up sending a SCTP_RESET_STREAMS packet which needs to grab the sctpassociation lock. This means _on_sctpdec_pad_added simply cannot take the pc_lock and also it is not possible to postpone the channel creation as we need to link the pads right there. The solution is to introduce a more granular dc_lock that protects only the things that needs to be done to create the datachannel. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2186> |
||
|---|---|---|
| .. | ||
| fwd.h | ||
| gstwebrtc.c | ||
| gstwebrtcbin.c | ||
| gstwebrtcbin.h | ||
| gstwebrtcice.c | ||
| gstwebrtcice.h | ||
| gstwebrtcstats.c | ||
| gstwebrtcstats.h | ||
| icestream.c | ||
| icestream.h | ||
| meson.build | ||
| nicetransport.c | ||
| nicetransport.h | ||
| sctptransport.c | ||
| sctptransport.h | ||
| transportreceivebin.c | ||
| transportreceivebin.h | ||
| transportsendbin.c | ||
| transportsendbin.h | ||
| transportstream.c | ||
| transportstream.h | ||
| utils.c | ||
| utils.h | ||
| webrtcdatachannel.c | ||
| webrtcdatachannel.h | ||
| webrtcsdp.c | ||
| webrtcsdp.h | ||
| webrtctransceiver.c | ||
| webrtctransceiver.h | ||