Picks up a single fix to address a deadlock triggered when attempting to
configure an audio device that has been removed.
Differential Revision: https://phabricator.services.mozilla.com/D166736
Upstream commit: https://webrtc.googlesource.com/src/+/7e176c41b9818052d79d5e3065b36655edbebd6d
Get RTCCameraVideoCapturerTests working again
See commit
https://webrtc.googlesource.com/src/+/c8a6fb2bb8762de17008dee97c5fb6e762f7e056
where the setup methods for RTCCameraVideoCaptureTests' test cases were
lost. Both "setup" where XCTest instead looks for "setUp", and
"setupWithMockedCaptureSession" which isn't called explicitly anywhere.
This commit splits the old RTCCameraVideoCaptureTests into two;
RTCCameraVideoCaptureTests for tests using "setup", and
RTCCameraVideoCaptureTestsWithMockedCaptureSession for tests using
"setupWithMockedCaptureSession".
Bug: webrtc:8382
Change-Id: I64cefff744e12f62d65e04133512de1e10d17d95
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/288601
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Reviewed-by: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Commit-Queue: Kári Helgason <kthelgason@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38931}
Differential Revision: https://phabricator.services.mozilla.com/D166584
Started callback interface functionality to UniFFI. Currently this only
supports the async fire-and-forget use case, where Rust queues a JS
function to run, but doesn't wait (or `await`) for the response.
The basic system is:
- The JS code registers a callback interface handler with the C++
code. This handler is responsible for the specifics of invoking the
callback.
- The C++ code defines a function to call a JS handler. Once the JS
handler registers itself with C++, the C++ registers it's function
with Rust.
- The C++ code queues the call to the JS main thread.
- Because of how UniFFI handles callback interfaces, the C++ code can
be "dumb". UniFFI sends a object id, method id, and RustBuffer
encoding all arguments. This means C++ doesn't need to care about
the specific arguments, they get unpacked by JS.
I tried to keep the generated code as simple as possible by moving the
complexity to static code. For JS this meant writing a generic
`UniFFICallbackHandler` class in the static code that the generated code
constructs. For C++ this meant the generated code defines a
`UniFFIGetCallbackInterfaceInfo` function that returns a struct with all
the data specific to a callback interface (it's name, the UniFFI
scaffolding init function, etc). The static code can then define a
generic `QueueCallback` function that looks up the callback interface
info using the interface ID and then makes the call.
Allow UniFFI functions to run on the main thread rather than always
being dispatched to a worker thread. This allows us to test invoking
callback interfaces from the main thread thread. I don't think we will
use this much currently, since we don't want to block the main thread
for any significant amount of time. However, this will pair well with
the next step in the project which is async -- allowing async Rust
functions to call async JS functions. In that scenario, dispatching to
the worker thread is unnecessary.
Callback interface objects present a potential memory leak, since you
can easily create a cycle between a JS Callback object and a UniFFIed
Rust object, and the GC has no way of detecting it. To try to detect
these there's some shutdown code that checks that there are no callbacks
registered during shutdown and prevents any future callbacks from being
registered.
Added a `config.toml` file and code to parse it. This is needed to
specify which functions should run on the main thread.
Updated the git commits for the several UniFFI examples/fixtures.
Differential Revision: https://phabricator.services.mozilla.com/D156116
Upgrade winreg (currently used only by mozrunner) to 0.10.1.
As winreg 0.5.1 is currently listed as an exemption in `supply-chain`,
audit the new version as a blank slate, rather than performing an audit
of the diffs; this is both simpler and allows removing the exemption.
(There are some uses of `unsafe` that would be concerning in deployment
(more for reasons of stability than security), but the crate does
qualify as `safe-to-run`.)
winreg 0.5.1 is currently only used by mozrunner, which requires no
source changes for this upgrade.
Differential Revision: https://phabricator.services.mozilla.com/D165723
Andreas Pehrson
Matthew Gregan
Chris H-C
serge-sans-paille
Updatebot
Cosmin Sabou
Butkovits Atila
Gabriele Svelto
Norisz Fay
Mike Hommey
Kagami Sascha Rosylight
Cristian Tuns
Byron Campen [:bwc]
Nicolas Silva
Stanca Serban
Michael Froman
Ben Dean-Kawamura
Ray Kraesig