rtc::Thread::Dispose is only used in test code,
but complicates the main thread loop.
Bug: webrtc:8324
Change-Id: I2dccdadcdc932b9992958d1e70fb93d1879b7618
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272821
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37894}
Remote Peek function as unused
Move Get and Dispatch into private section to ensure they are not used
from outside.
Bug: webrtc:9702
Change-Id: Ibd0b236fe43543d60f97f988524526493bbeaaa7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272804
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37889}
While transitioning to TimeDelta, WebRTC and Chromium has a
different idea about what type rtc::Event::kForever is. Code
can't assume rtc::Event::kForever is the same type as timed
wait arguments.
Bug: webrtc:14366
Change-Id: I4783c7de6d567c70b211de9aa9889417f6fafba1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272060
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37810}
This combines the below IPv6 fixes into the field trial
WebRTC-IPv6NetworkResolutionFixes:
1. Prefer global IPv6 address over link local
2. Use address family when resolving STUN hostname
WebRTC-PreferGlobalIPv6ToLinkLocal is currently in Dev but will be
rolled back temporarily.
Bug: webrtc:14334, webrtc:14131
Change-Id: I1fb3f55c4c5f3c5c0b441ece30e72cf393e074d0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271340
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Sameer Vijaykar <samvi@google.com>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37754}
The current behaviour is to lookup using AF_UNSPEC, which leaves
the decision up to the getaddrinfo implementation, then filter to
resolved addresses matching the network family anyway.
Looking up using the network's family upfront avoids resolving to
an unusable address.
Bug: webrtc:14319, webrtc:14131
Change-Id: I4997452dc26aeb82e5d2890701721e7d477803a8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/270625
Commit-Queue: Sameer Vijaykar <samvi@google.com>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37753}
The input SocketAddress for STUN host lookup is constructed with just
the hostname, so the family is AF_UNSPEC. So added an overload with a
target family to distinguish this from the family of the input addr.
Bug: webrtc:14319, webrtc:14131
Change-Id: Ia5ac5aa2e894e0c4dfb4417e3e8a76a6cec3ea71
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/270624
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Sameer Vijaykar <samvi@google.com>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@google.com>
Cr-Commit-Position: refs/heads/main@{#37750}
that rtc::Location parameter was used only as extra information for the
RTC_CHECKs directly in the function, thus call stack of the crash should
provide all the information about the caller.
Bug: webrtc:11318
Change-Id: Iec6dd2c5de547f3e1601647a614be7ce57a55734
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/270920
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37748}
clangd ignores ASSERT_EXCLUSIVE_LOCK macro attached to an inline function in header, thus IDEs relying on clangd issue false positive warnings about members acceesses without the check of the current sequence.
Attaching assert attribute to an inlined lambda function seems to solve that issue
Bug: None
Change-Id: I6199fee26061aa4223f2e3ea7b7b14bb5820c0bc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/270480
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37678}
The goal of this CL is to create a new LogSink::OnLogMessage API which
propagates the source location of the log to the log sinks.
Bug: b/238157120
Change-Id: I5a12bf80fd9c5569ed7aa1ef9185eee58830b19f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269249
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37672}
This replaces the former WriteFatalLogAndAbort function with the two new
WriteFatalLog functions that're already submitted as overrides in
Chromium.
The default implementations of these are not defined under
WEBRTC_CHROMIUM_BUILD.
Bug: chromium:1216177
Change-Id: I207e1f96f14094d742a51849f4fa6b4f1022333e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269780
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Peter Boström <pbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37652}
This adds a file,line version of this function (not yet committed) as
Chromium logging uses LogMessage(file, line, severity) and needs this
information to give better logs.
The two versions of this method will be implemented in webrtc_overrides/
and then committed to Chromium. At this point checks.cc will move its
anonymous-namespace version of this function (and be renamed) to
match this definition, but only define it when not building with
Chromium.
At this point WriteFatalLog will be using LogMessage(LOG_FATAL) to crash
in Chromium allowing us to upload better crash dumps and stacks to crash
reporting.
Bug: chromium:1216177
Change-Id: I3fd6a84cdfbb2552a5e628d46257bd7a00c9e6dc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269288
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Peter Boström <pbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37646}
This removes the unused field trials
`WebRTC-SimulcastScreenshareUpswitchHysteresisPercent` and
`WebRTC-SimulcastScreenshareUpswitchHysteresisPercent` as well as the
`video_hysteresis` and `screenshare_hysteresis` parameters in
`WebRTC-VideoRateControl`.
The hysteresis parameters in `WebRTC-StableTargetRate` are currently
left, their future is unclear...
Bug: webrtc:9734
Change-Id: I9e6bbe4b630a0501d365bf69e87e65164c500122
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269207
Reviewed-by: Emil Lundmark <lndmrk@webrtc.org>
Auto-Submit: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37635}
instead of using Lock/Unlock attributes, use Assert attribute to annotate code is running on certain task queue or thread.
Such check better matches what is checked, in particular allows to
recheck (and thus better document) currently used task queue
Bug: None
Change-Id: I5bc1c397efbc8342cf7915093b578bb015c85651
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269381
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37619}
This ctor has been deprecated for a while and it should be unused
by WebRTC clients.
Bug: None
Change-Id: I7d33ae24eefafe48924011f55fb53150b717d593
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269180
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37584}
cricket::Interpolate Interpolate is constexpr and therefore requires
UnitBase::operator* to be constexpr too. For consistency mark UnitBase::operator/ constexpr as well.
Bug: chromium:819294
Change-Id: I6f1bf812a452de3307b0720a00b85a127631992e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/268186
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37495}
Lots of code call rtc::Thread directly instead of through TaskQueueBase
interface, thus to continue migration step by step rtc::Thread needs
to implement both old and new TaskQueueBase interfaces.
Bug: webrtc:14245
Change-Id: Ie7cac897a4c8a6227b8d467a39adb30aec6f1318
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267984
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37474}
