Files
platform-external-webrtc/api
Tomas Gunnarsson 6cd4058504 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}
2021-02-08 14:45:25 +00:00
..
2020-09-23 09:40:25 +00:00
2021-02-08 14:03:34 +00:00
2020-10-21 08:57:13 +00:00
2019-06-03 08:15:09 +00:00
2020-09-07 12:57:15 +00:00
2020-09-07 12:57:15 +00:00
2019-02-01 13:24:47 +00:00
2021-01-28 14:22:52 +00:00

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 in api/path/to/foo.h, it should be defined in api/path/to/foo.cc.
  • Headers in api/ should, if possible, not #include headers outside api/. 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 in api/, on the other hand, are free to #include headers outside api/.

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.