6b143c1c06
This reverts commit 6cd405850467683cf10d05028ea0f644a68a91a4. Reason for revert: Breaks WebRTC Chromium FYI Bots First failure: https://ci.chromium.org/p/chromium/builders/webrtc.fyi/WebRTC%20Chromium%20FYI%20Android%20Tests%20%28dbg%29%20%28L%20Nexus5%29/1925 Failed tests: WebRtcDataBrowserTest.CallWithSctpDataAndMedia WebRtcDataBrowserTest.CallWithSctpDataOnly Original change's description: > Fix unsynchronized access to mid_to_transport_ in JsepTransportController > > * Added several thread checks to JTC to help with programmer errors. > * Avoid a few Invokes() to the network thread here and there such > as for fetching sctp transport name for getStats(). The transport > name is now cached when it changes on the network thread. > * JsepTransportController instances now get deleted on the network > thread rather than on the signaling thread + issuing an Invoke() > in the dtor. > * Moved some thread hops from JTC over to PC which is where the problem > exists and also (imho) makes it easier to see where hops happen in > the PC code. > * The sctp transport is now started asynchronously when we push down the > media description. > * PeerConnection proxy calls GetSctpTransport directly on the network > thread instead of to the signaling thread + blocking on the network > thread. > * The above changes simplified things for webrtc::SctpTransport which > allowed for removing locking from that class and delete some code. > > Bug: webrtc:9987, webrtc:12445 > Change-Id: Ic89a9426e314e1b93c81751d4f732f05fa448fbc > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/205620 > Commit-Queue: Tommi <tommi@webrtc.org> > Reviewed-by: Harald Alvestrand <hta@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#33191} TBR=tommi@webrtc.org,hta@webrtc.org Change-Id: I7b2913d5133807589461105cf07eff3e9bb7157e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: webrtc:9987 Bug: webrtc:12445 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/206466 Reviewed-by: Guido Urdaneta <guidou@webrtc.org> Commit-Queue: Guido Urdaneta <guidou@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33204}
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.