Commit graph

3 commits

Author SHA1 Message Date
Danil Chapovalov
c05a1be5b4 Migrate remaining webrtc usage of TaskQueueBase to absl::AnyInvocable
Bug: webrtc:14245
Change-Id: I8de2c23da5fbdfc0b1efbbe07fb6e8de744424a3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/268191
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37565}
2022-07-20 08:15:08 +00:00
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
Victor Boivie
de88b08b94 dcsctp: Add TaskQueue based timeout implementation
This is about doing the best with what we have. As delayed tasks can't
be cancelled, and dcSCTP timers will almost always be stopped or
restarted, and will generally only expire on packet loss.

This implementation will post a delayed task whenever a Timeout is
started. Whenever it's stopped or restarted, it will keep the scheduled
delay task running (there's no alternative), but it will also not start
a new delayed task on subsequent starts/restarts. Instead, it will wait
until the original delayed task has triggered, and will then - if the
timer is still running, which it probably isn't - post a new delayed
task with the remainder of the the duration.

There is special handling for when a shorter duration is requested, as
that can't re-use the scheduled task, but that shouldn't be very common.

Bug: webrtc:12614
Change-Id: I7f3269cabf84f80dae3b8a528243414a93d50fc4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217223
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33904}
2021-05-03 16:12:30 +00:00