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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #49 from Miguel París Díaz <mparisdiaz at gmail.com> ---
Hello,
I have found another race condition due not only the tee but the pad too.
I have done a simple app (attachment 330267) and a simple commit in gstpad.c
(attachment 330268) to force this race condition, which provokes a sticky event
misordering in the peer pad of the tee src pads
(in our case in the sink pad of the second fakesink)

There are 2 threads:
 - streaming_thread: managed by the task of the SrcPad of a FakeSrc
 - app_thread: performs the creation and linkage of the tee src pads

The race condition is:
  1 - [app_thread] tee0 and fakesink0 are linked
  2 - [streaming_thread] stream-start event arrives to the tee0:sink pad
    2.1 - it is forwarded to tee0:src_0 and fakesink0:sink
  3 - [app_thread] Just:
      - after forwarding the event to all tee src pads
      - and bedore storing the sticky event in tee0:sink pad
    a new tee src pad is added (tee:src_1)
      - The stream-start is NOT forwarded because the forwarding iteration has
already finished
      - the stream start is NOT stored because tee0:sink has stored the event
yer
  4 - [streaming_thread] caps event arrives to the tee0:sink pad
    4.1 - it is forwarded to all tee src pads and to fakesink0:sink and
fakesink:1:sink pads
        So, fakesink1:sink receives the caps event without having the
stream-start event
  5 - [app_thread]
    5.1 - fakesink1:sink is unlinked from tee:src_1
    5.2 - tee:src_1 is released
    5.3 - fakesink1:sink is linked to a new tee src pad (tee:src_2)
      5.3.1 - stream-start event is stored in tee:src_2
      5.3.2 - stream-start event is tried to store into fakesik1:sink
            Here we have the misordering error

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