[Bug 752213] tee: Avoid race condition while forwarding sticky events

[GStreamer (GNOME Bugzilla)]

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

--- Comment #43 from Miguel París Díaz <mparisdiaz at gmail.com> ---
OK, I see the point and you are right, in these cases with the last patch it
would *always* fail.
But with the current implementation and even with the other patches proposed in
 in this thread (based on flags and cookies), it would *sometimes* fail if the
non desirable race condition happens.
This race condition is:
 1 - New src pad when the sink pad does not have any sticky event
 2 - Forward sticky events from sink pad to src pad (but there is not any
event)
 3 - A new sticky event (eg: caps) arrives to the sink pad (but it is not
forwarded to the src pad because it has not been added yet).
 4 - The src pad is added to the tee element.
 5 - Demuxers or apps fail because there is not any caps in the src pad.

To solve this problem the forwarding sticky events and adding the pad must be
done in a critical section, the same that the event function of the sink pad.
This critical section could be performed with the patch
https://bug752213.bugzilla-attachments.gnome.org/attachment.cgi?id=324416, but:
> The main problem is btw not that it's expensive, but that every unneeded
> mutex is a liability that might cause your future self a deadlock later

If I am not wrong, this only can happen if this mutex (mutex_events) is locked
into another section locked by a mutex-X && mutex-X is locked into another
section locked by this mutex (mutex_events).
Where mutex-X only can be:
 - GST_OBJECT_LOCK (pad)
 - GST_OBJECT_LOCK (tee)

So, can happen that
 - a new src pad of the tee is requeste
 - or gst_tee_sink_event is called
with mutex-X locked?

Other situations that can cause a deadlock?

Could we do a better solution taking into account that the cookies and flags
ones did not fix the problem?

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