Skip to content

tests/clock: avoid a race cranking

Scenario:

  • Source 1 requesting and waiting a clock id
  • Source 2 requesting and waiting on a clock id
  • Test attempting to crank both sources in the same GstHarness

gst_test_clock_crank() originally dropped locks between the retrieving of the next clock id and advancing to the next clock id. This would mean that both sources would race each other attempting to complete their clock waits. Sometimes the operations would be performed in the correct order, other times they would not and a FALSE return value would be produced.

This would lead to an assertion in gst_harness_push_from_src() expecting that all clock cranks to succeed.

Fix by ensuring that the clock wait produced is dealt with before processing the next by not dropping the relevant locks after retrieving the next clock id.

cc @hgr

Edited by Matthew Waters

Merge request reports