
* 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}
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 “.h
and.cc
files 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#include
headers 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. .cc
files inapi/
, on the other hand, are free to#include
headers 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.