1d2fa9a1c3
In real life, when a Timeout expires, the caller is supposed to call DcSctpSocket::HandleTimeout directly, as the Timeout that just expired is stopped (it just expired), but the Timer still believes it's running. The system is not in a consistent state. In tests, all timeouts were evaluated at the same time, which, if two timeouts expired at the same time, would put them both as "not running", and with their timers believing they were running. So if you would do any operation on a timer whose timeout had just expired, the timeout would assert saying that "you can't stop a stopped timeout" or similar. This isn't relevant in non-test scenarios. Solved by expiring timeouts one by one. Bug: webrtc:12614 Change-Id: I79d006f4d3e96854d77cec3eb0080aa23b8569cb Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217560 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33925}
WebRTC is a free, open software project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. The WebRTC components have been optimized to best serve this purpose.
Our mission: To enable rich, high-quality RTC applications to be developed for the browser, mobile platforms, and IoT devices, and allow them all to communicate via a common set of protocols.
The WebRTC initiative is a project supported by Google, Mozilla and Opera, amongst others.
Development
See here for instructions on how to get started developing with the native code.
Authoritative list of directories that contain the native API header files.
More info
- Official web site: http://www.webrtc.org
- Master source code repo: https://webrtc.googlesource.com/src
- Samples and reference apps: https://github.com/webrtc
- Mailing list: http://groups.google.com/group/discuss-webrtc
- Continuous build: https://ci.chromium.org/p/webrtc/g/ci/console
- Coding style guide
- Code of conduct
- Reporting bugs