Alicia Boya García 9ca194d8cc harness: Fix race condition when torn down during the handling of a non-serialized query or event ... It's possible and normal to tear down a harness while the pipeline is running. At the same time, it's desired for the `gst_harness_pad_link_tear_down()` function to be synchronous. This has created the conflict where the main thread may request a harness to be torn down while it's in use or about to be used by a pad in the streaming thread. The previous implementation of `gst_harness_pad_link_tear_down()` tried to handle this by taking the stream lock of the harnessed pad and resetting all the pad functions while holding it. That approach was however insufficient to handle the case where a non-serialized event or query is being handled or about to be handled in a different thread. This edge case was one race condition behind the flakes in the flvmux check tests -- the rest being covered by https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2803. This patch fixes the problem by adding an intermediate ref-counted object, GstHarnessLink, which replaces the usage of the HARNESS_KEY association. GstHarnessLink allows the pad functions such as event, query and chain to borrow a reference to GstHarness and more importantly, to lock the GstHarnessLink during their usage to block (delay) its destruction until no users are left, and guarantee that any future user will not receive an invalid GstHarness handle past its destruction. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5017>		2023-07-12 13:18:00 +00:00
..
gst	harness: Fix race condition when torn down during the handling of a non-serialized query or event	2023-07-12 13:18:00 +00:00
meson.build	Move files from gstreamer into the "subprojects/gstreamer/" subdir	2021-09-24 16:13:07 -03:00