Created attachment 205612 [details] [review]
pad: also flush FLUSH_STOP if pad not active

Consider a FLUSH_STOP moving through the pipeline in one thread, while other thread (mainloop) is performing PAUSED_TO_READY.  While such behaviour is typically rare (FLUSH_STOP usually occurs with seeking and done by mainloop), it is (AFAIK) not "illegal" and can in fact occur in e.g. GNonLin context.

The following race can occur:
* mainloop performs pre_activate for src pad
* mainloop performs queue src pad (de)activation 
(setting src result, unblocking loop etc)
* core processes FLUSH_STOP for sink pad; it notices that pad has been deactivated so will not clear flush flag, but afaics it will still invoke the pad's event function

* processing an event while flushing is Not Good.  For queue-like elements, this could also mean loop task being started again and so even worse.
Particularly so when mainloop then performs src pad post_activate, which tries to get STREAM_LOCK (and will not get since a task is running).

Looks like this has been fixed in 0.11 (slightly differently); would seem to be proper in 0.10 as well unless there is some behaviour to maintain there.