7f16fcda0f
This reverts commit fe53fec24e02d2d644220f913c3f9ae596bbb2d9. Reason for revert: Speculative revert, may be breaking downstream project Original change's description: > [DataChannel] Send and receive packets on the network thread. > > 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} Bug: webrtc:11547 Change-Id: Id0d65594bf727ccea5c49093c942b09714d101ad No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/300341 Auto-Submit: Andrey Logvin <landrey@webrtc.org> Owners-Override: Andrey Logvin <landrey@webrtc.org> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/main@{#39764}
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.