fe53fec24e
This updates sctp channels, including work that happens between the data channel controller and the transport, to run on the network thread. Previously all network traffic related to data channels was routed through the signaling thread before going to either the network thread or the caller's thread (e.g. js thread in chrome). Now the calls can go straight from the network thread to the JS thread with enabling a special flag on the observer (see below) and similarly calls to send data, involve 2 threads instead of 3. * Custom data channel observer adapter implementation that maintains compatibility with existing observer implementations in that notifications are delivered on the signaling thread. The adapter can be explicitly disabled for implementations that want to optimize the callback path and promise to not block the network thread. * Remove the signaling thread copy of data channels in the controller. * Remove several PostTask operations that were needed to keep things in sync (but the need has gone away). * Update tests for the controller to consistently call TeardownDataChannelTransport_n to match with production. * Update stats collectors (current and legacy) to fetch the data channel stats on the network thread where they're maintained. * Remove the AsyncChannelCloseTeardown test since the async teardown step has gone away. * Remove `sid_s` in the channel code since we only need the network state now. * For the custom observer support (with and without data adapter) and maintain compatibility with existing implementations, added a new proxy macro that allows an implementation to selectively provide its own implementation without being proxied. This is used for registering/unregistering a data channel observer. * Update the data channel proxy to map most methods to the network thread, avoiding the interim jump to the signaling thread. * Update a plethora of thread checkers from signaling to network. Bug: webrtc:11547 Change-Id: Ib4cff1482e31c46008e187189a79e967389bc518 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299142 Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org> Reviewed-by: Henrik Boström <hbos@webrtc.org> Cr-Commit-Position: refs/heads/main@{#39760}
How to write code in the api/ directory
Mostly, just follow the regular style guide, but:
- Note that
api/code is not exempt from the “.hand.ccfiles come in pairs” rule, so if you declare something inapi/path/to/foo.h, it should be defined inapi/path/to/foo.cc. - Headers in
api/should, if possible, not#includeheaders outsideapi/. It’s not always possible to avoid this, but be aware that it adds to a small mountain of technical debt that we’re trying to shrink. .ccfiles inapi/, on the other hand, are free to#includeheaders outsideapi/.
That is, the preferred way for api/ code to access non-api/ code is to call
it from a .cc file, so that users of our API headers won’t transitively
#include non-public headers.
For headers in api/ that need to refer to non-public types, forward
declarations are often a lesser evil than including non-public header files. The
usual rules still apply, though.
.cc files in api/ should preferably be kept reasonably small. If a
substantial implementation is needed, consider putting it with our non-public
code, and just call it from the api/ .cc file.