Created attachment 363788 [details] [review]
gstpad: Make calls to GstPadActivateFunction MT-safe

checking whether we already were in the target GstPadMode was being
done too early and there was the risk that we *would* end up
(de)activating a pad more than once.

Instead, re-do the check for pad mode when entering the final pad
(de)activation block.

Note that this commit does not solve the following problem:
* Thread 1 calls gst_pad_activate()
* Thread 2 was currently doing the (de)activation
* Thread 1 assumes pad (de)activation has happened and does something with it while the (de)actvation hasn't *actually* completed.

Created attachment 363816 [details] [review]
gstpad: Make pad (de)activation atomic

The following could happen previously:
* T1: calls gst_pad_set_active()
* T2: currently (de)activating it
* T1: gst_pad_set_active() returns, caller assumes that the pad has
  completed the requested (de)activation ... whereas it is not
  the case since the actual (de)activation in T2 might still be
  going on.

To ensure atomicity of pad (de)activation, we use a internal
variable (and cond) to ensure only one thread at a time goes through
the actual (de)activation block

commit d915dd4b20ffdcb417ea4b46a8dd9010c7ce7bf9 (HEAD -> master, origin/master, origin/HEAD)
Author: Edward Hervey <edward@centricular.com>
Date:   Thu Nov 16 10:47:46 2017 +0100

    gstpad: Make pad (de)activation atomic
    
    The following could happen previously:
    * T1: calls gst_pad_set_active()
    * T2: currently (de)activating it
    * T1: gst_pad_set_active() returns, caller assumes that the pad has
      completed the requested (de)activation ... whereas it is not
      the case since the actual (de)activation in T2 might still be
      going on.
    
    To ensure atomicity of pad (de)activation, we use a internal
    variable (and cond) to ensure only one thread at a time goes through
    the actual (de)activation block
    
    https://bugzilla.gnome.org/show_bug.cgi?id=790431

commit 80262013ca553fa5b35e5c638893d3512a3dd7dc
Author: Edward Hervey <edward@centricular.com>
Date:   Thu Nov 16 08:26:12 2017 +0100

    gstpad: Make calls to GstPadActivateFunction MT-safe
    
    checking whether we already were in the target GstPadMode was being
    done too early and there was the risk that we *would* end up
    (de)activating a pad more than once.
    
    Instead, re-do the check for pad mode when entering the final pad
    (de)activation block.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=790431

I have reported a deadlock on platform IMX that started to happen with WPE (WebKit) after this two commits in bug 792341