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}
This should avoid the situation where WebRTC's GN check is green and
Chromium (which turns it ON for //third_party/webrtc) fails.
Bug: webrtc:12614
Change-Id: Id4c06ac57e9faa07c5e43491a61fbc093c68a40d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217221
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33900}
Those were found when trying to build within Chromium's codebase.
Bug: webrtc:12614
Change-Id: Ic3f7a266ad4b5d816a693645e1e909fc39d513c3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217220
Reviewed-by: Victor Boivie <boivie@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33896}
Ensuring that timer durations never go beyond a safe maximum duration
and that timer IDs are not re-used.
Bug: webrtc:12614
Change-Id: I227a2e9933da16669dc6ea0a39c570892010ba2c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215063
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33860}
To be able to use them type-safely, they should support native
operators (e.g. adding a time and a duration, or subtracting two time
values), as the alternative is to manage them as numbers.
Yes, this makes them behave a bit like absl::Time/absl::Duration.
Bug: webrtc:12614
Change-Id: I4dea12e33698a46e71fb549f44c06f2f381c9201
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215143
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33725}
Timer is a high-level timer (in contrast to the low-level `Timeout`
class). Timers are started and can be stopped or restarted. When a timer
expires, the provided callback will be triggered.
Timers can be configured to do e.g. exponential backoff when they expire
and how many times they should be automatically restarted.
Bug: webrtc:12614
Change-Id: Id5eddd58dd0af62184b10dd1f98e3e886e3f1d50
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213350
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33666}
