"Race" when (de)activating pads
@bilboed
Submitted by Edward Hervey Link to original bug (#792595)
Description
Currently the following scenario can happen.
- Thread 1 (from downstream elements) wants to reconfigure the scheduling mode of an upstream element (such as typefind)
- Thread 2 (from the application or higher-level element) wants to deactivate the scheduling of that element.
The following "race" happens:
- T2 calls gst_pad_set_active(pad, FALSE)
** T2 calls activate_mode_internal(pad, ..., FALSE)
** T2 pad was currently active, it eventually calls pre_activate(pad, GST_PAD_MODE_NONE), which sets in_activation to TRUE and GST_PAD_MODE(pad) to GST_PAD_MODE_NONE
** T2 calls the actual activation function - T1 calls gst_pad_activate_mode(pad, ..., TRUE)
** T2 calls activate_mode_internal(pad, ...., TRUE)
** T2 has GST_PAD_MODE_NONE, so carries on to call pre_activate
** T2 in pre_activate sees that in_activation is TRUE, so waits for the other thread to finish (and set in_activation to FALSE) - T2 finished calling the actual activation function and calls post_activate
** T2 set in_activation to FALSE and resumes succesfully, i.e. telling the caller that the pad is deactivated - T1 can resume activation and actually activates the pad
=> T2 assumes the pad is deactivated .... but it's not. (Note that the exact opposite could also happen).
Not entirely sure how this could be solved though.