Because rtc::Thread inherits from TaskQueueBase, it already implements
a pair of PostTask/PostDelayedTask methods that we want to keep. But in
addition to those, rtc::Thread defines its own PostTask/PostDelayedTask
using templates. These are the versions that we want to deprecate.
They were originally implemented prior to rtc::Thread inheriting from
TaskQueueBase. We want to deprecate them because...
- We don't want to have multiple code paths that do the same thing.
- We want to move away from rtc::Thread to TaskQueueBase long-term.
- These versions are not overridable in Chromium.
- These versions don't have high/low precision versions of PDT.
Helper methods are added to rtc::Thread so that callers don't have to
wrap every lambda in webrtc::ToQueuedTask() and update dependencies.
Bug: webrtc:13582
Change-Id: I58702c53f4cb3705681bd9f1ea16b7aaa5052c18
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/247660
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Markus Handell <handellm@google.com>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35750}
Enumerating windows owned by the current process on Windows has some
complications due to the GetWindowText*() APIs potentially causing a
deadlock. The APIs will send messages to the window's message loop, and
if the message loop is waiting on this operation we will enter a
deadlock.
I previously put in a mitigation for this [1] which brought the
incidence rate down by an order of magnitude, but we are still seeing
this issue fairly frequently.
So, I've added DesktopCaptureOption enumerate_current_process_windows
which allows consumers to avoid this issue completely by ignoring
these potentially problematic windows.
By default the flag is set to true which equates with the current
behavior, consumers can set the flag to false to get the new behavior.
I've also updated all the capturers that enumerate windows on Windows
to respect the option.
[1] https://webrtc-review.googlesource.com/c/src/+/195365
Bug: chromium:1152841
Change-Id: I0e0d868957d6fbe1e607a440b3a909d005c93ccf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219380
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#34191}
For some time now, calls to EnumerateCapturableWindows could lead to a
deadlock if an application's main thread is waiting on the thread that
is running EnumerateCapturableWindows. This is because calls to
GetWindowText and GetWindowTextLength send a message to the window if
the window is owned by the current process. Since the main thread is
waiting on us, it will never reply to this message and we will hang.
This happens occasionally in Chromium when tearing down the
NativeDesktopMediaList object, e.g. when a user clicks "cancel" on
the capture target picker.
We can avoid this deadlock by checking if the window we are querying
is owned by the current process, and if it is then we must ensure it
is responding to messages before we call a GetWindowText* API.
This change also adds a unit test for this scenario. We create a
window and force it to be unresponsive by creating a deadlock, and
then call GetWindowList and (with the new changes) we should not
hang. Without the new changes to GetWindowListHandler, this test
would hang.
Change-Id: I2523cd735f96fd7ea60708c30cd22e5b525803f0
Bug: chromium:1152841
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/195365
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#32734}
