Henrik Boström b951dc6f4c Allow specifying delayed task precision of dcsctp::Timer.
Context: The timer precision of PostDelayedTask() is about to be lowered
to include up to 17 ms leeway. In order not to break use cases that
require high precision timers, PostDelayedHighPrecisionTask() will
continue to have the same precision that PostDelayedTask() has today.
webrtc::TaskQueueBase has an enum (kLow, kHigh) to decide which
precision to use when calling PostDelayedTaskWithPrecision().

See go/postdelayedtask-precision-in-webrtc for motivation and a table of
delayed task use cases in WebRTC that are "high" or "low" precision.

Most timers in DCSCTP are believed to only be needing low precision (see
table), but the delayed_ack_timer_ of DataTracker[1] is an example of a
use case that is likely to break if the timer precision is lowered (if
ACK is sent too late, retransmissions may occur). So this is considered
a high precision use case.

This CL makes it possible to specify the precision of dcsctp::Timer.
In a follow-up CL we will update delayed_ack_timer_ to kHigh precision.

[1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/net/dcsctp/rx/data_tracker.cc;l=340

Bug: webrtc:13604
Change-Id: I8eec5ce37044096978b5dd1985fbb00bc0d8fb7e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/249081
Reviewed-by: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35809}
2022-01-26 18:40:24 +00:00
..
2021-11-30 10:31:16 +00:00
2022-01-24 11:45:08 +00:00
2021-08-16 14:38:57 +00:00
2021-11-23 08:37:36 +00:00
2021-08-31 14:27:49 +00:00
2021-12-14 21:16:18 +00:00
2021-12-03 12:01:14 +00:00
2021-06-11 12:59:37 +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/. Its not always possible to avoid this, but be aware that it adds to a small mountain of technical debt that were 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 wont 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.