When flushing and draining at the same time from different threads without synchronization, one of them may fail and in the worst case, both fail, and the pipeline gets permanently stuck in EOS state. I'm dealing with a game that drains the Video Decoder MFT immediately after sending a stop command to the media session. In some cases, after the session is started again, the decoder does not output any samples anymore. The simple instance of this bug (with only one of them failing) stems from either drain-related events being pushed while the src pad is flushing, or flush-related events being pushed while the src pad is EOS. This does not cause any problems in the application. In the more complex case, the flush-stop event is processed by some pads (src in particular) but not yet the entire pipeline when a context switch happens, meaning that when the draining thread pushes its EOS event, it fails at a later pad (complete_drain then also fails), but is still stored as sticky in the src pad. After flush-stop finishes propagating, the stored EOS event then also propagates, leaving all pads in EOS state. This is the main problem I'm concerned about. I'm attaching `GST_DEBUG="4,WINE:9,GST_PADS:6,GST_EVENT:6"` logs for the EOS bug, as well as a test program. Note that the EOS case is comparatively rare. I'm unsure if this is the best fix for this issue, feel free to suggest something different. [flush-drain.c](/uploads/4e48cdea79a32867974c49b0aa2637c6/flush-drain.c) [flush-drain-bug.log](/uploads/9e873f0e807ecc665565a152bbade9d7/flush-drain-bug.log) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9937