It was used only to break the circular dependency between SocketServer
and Thread at destruction time. Replaced with a method call to
SetMessageQueue(nullptr).
Bug: webrtc:11943
Change-Id: I0606d473ad79655cca28411bb02c21e21d2d7220
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215587
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33807}
Also removing a count check from DestroyTransceiverChannel that's
not useful right now. We can bring it back when we have
DestroyChannelInterface better under control as far as Invokes goes.
Bug: none
Change-Id: I8e9c55a980f8f20e8b996fdc461fd90b0fbd4f3d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215201
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33730}
This is useful to understand how often we block in certain parts of the
api and track improvements/regressions.
There are two macros, both are only active for RTC_DCHECK_IS_ON builds:
* RTC_LOG_THREAD_BLOCK_COUNT()
Example:
void MyClass::MyFunction() {
RTC_LOG_THREAD_BLOCK_COUNT();
thread_->Invoke<void>([this](){ DoStuff(); });
}
When executing this function during a test, the output could be:
(my_file.cc:2): Blocking MyFunction: total=1 (actual=1, would=0)
The words 'actual' and 'would' reflect whether an actual thread switch
was made, or if in the case of a test using the same thread for more
than one role (e.g. signaling, worker, network are all the same thread)
that an actual thread switch did not occur but it would have occurred
in the case of having dedicated threads. The 'total' count is the sum.
* RTC_DCHECK_BLOCK_COUNT_NO_MORE_THAN(x)
Example:
void MyClass::MyFunction() {
RTC_LOG_THREAD_BLOCK_COUNT();
thread_->Invoke<void>([this](){ DoStuff(); });
thread_->Invoke<void>([this](){ MoreStuff(); });
RTC_DCHECK_BLOCK_COUNT_NO_MORE_THAN(1);
}
When a function is known to have blocking calls and we want to not
regress from the currently known number of blocking calls, we can use
this macro to state that at a certain point in a function, below
where RTC_LOG_THREAD_BLOCK_COUNT() is called, there must have occurred
no more than |x| (total) blocking calls. If more occur, a DCHECK will
hit and print out what the actual number of calls was:
# Fatal error in: my_file.cc, line 5
# last system error: 60
# Check failed: blocked_call_count_printer.GetTotalBlockedCallCount() <= 1 (2 vs. 1)
Bug: webrtc:12649
Change-Id: Ibac4f85f00b89680601dba54a651eac95a0f45d3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213782
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33632}
As documented in webrtc:11908 this cleanup is fairly invasive and
when a part of a frequently executed code path, can be quite costly
in terms of performance overhead. This is currently the case with
synchronous calls between threads (Thread) as well with our proxy
api classes.
With this CL, all code in WebRTC should now either be using MessageHandlerAutoCleanup
or calling MessageHandler(false) explicitly.
Next steps will be to update external code to either depend on the
AutoCleanup variant, or call MessageHandler(false).
Changing the proxy classes to use TaskQueue set of concepts instead of
MessageHandler. This avoids the perf overhead related to the cleanup
above as well as incompatibility with the thread policy checks in
Thread that some current external users of the proxies would otherwise
run into (if we were to use Thread::Send() for synchronous call).
Following this we'll move the cleanup step into the AutoCleanup class
and an RTC_DCHECK that all calls to the MessageHandler are setting
the flag to false, before eventually removing the flag and make
MessageHandler pure virtual.
Bug: webrtc:11908
Change-Id: Idf4ff9bcc8438cb8c583777e282005e0bc511c8f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/183442
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32049}
Send() was creating an instance of AutoThread for every call,
which is equivalent of instantiatiating a whole new instance of
Thread (AutoThread inherits from Thread) and not just ensuring that
a thread instance is registered for the current thread, as the
comments indicated.
Bug: webrtc:11908
Change-Id: I8bbb43ca83c30d9f5e1928205b3611271ecad053
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/183441
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32037}
This name change communicates that the recursive critical section
should not be used for new code.
The relevant files are renamed rtc_base/critical_section* ->
rtc_base/deprecated/recursive_critical_section*
Bug: webrtc:11567
Change-Id: I73483a1c5e59c389407a981efbfc2cfe76ccdb43
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179483
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31754}
Policy will allow explicitly specify thread between which invokes are
allowed, or explicitly forbid any invokes.
Change-Id: I360e7cba3ce1c21abd5047c6f175d8c4e0e99c6f
Bug: webrtc:11728
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177526
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31604}
This reverts commit 28685dc08c.
Reason for revert: Speculative reland after looking into downstream
failures. It's possible that carryover state from unrelated tests
running in parallel was causing failures.
Original change's description:
> Revert "Make sure that "current" rtc::Thread instances are always current for TaskQueueBase."
>
> This reverts commit 46b3bc6c24.
>
> Reason for revert: Speculative revert. Breaks downstream project
>
> Original change's description:
> > Make sure that "current" rtc::Thread instances are always current for TaskQueueBase.
> >
> > This is a necessary part of fulfilling the TaskQueueBase
> > interface. If a thread does not register as the current TQ, yet offers
> > the TQ interface, TQ 'current' checks will not work as expected and
> > code that relies them (TaskQueueBase::Current() and IsCurrent())
> > will run in unexpected ways.
> >
> > Bug: webrtc:11572
> > Change-Id: Iab747bc474e74e6ce4f9e914cfd5b0578b19d19c
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175080
> > Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> > Commit-Queue: Tommi <tommi@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#31254}
>
> TBR=mbonadei@webrtc.org,tommi@webrtc.org
>
> Change-Id: I69ff3355f0ec447b25604bd95fdacbdb4d4f3f27
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: webrtc:11572
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175104
> Reviewed-by: Artem Titov <titovartem@webrtc.org>
> Commit-Queue: Artem Titov <titovartem@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31259}
TBR=mbonadei@webrtc.org,tommi@webrtc.org,titovartem@webrtc.org
# Not skipping CQ checks because this is a reland.
Bug: webrtc:11572
Change-Id: I00c82d99af8e05851769e09cb682b5b73895a6f3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175133
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31273}
This reverts commit 46b3bc6c24.
Reason for revert: Speculative revert. Breaks downstream project
Original change's description:
> Make sure that "current" rtc::Thread instances are always current for TaskQueueBase.
>
> This is a necessary part of fulfilling the TaskQueueBase
> interface. If a thread does not register as the current TQ, yet offers
> the TQ interface, TQ 'current' checks will not work as expected and
> code that relies them (TaskQueueBase::Current() and IsCurrent())
> will run in unexpected ways.
>
> Bug: webrtc:11572
> Change-Id: Iab747bc474e74e6ce4f9e914cfd5b0578b19d19c
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175080
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Tommi <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31254}
TBR=mbonadei@webrtc.org,tommi@webrtc.org
Change-Id: I69ff3355f0ec447b25604bd95fdacbdb4d4f3f27
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11572
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175104
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31259}
This is a necessary part of fulfilling the TaskQueueBase
interface. If a thread does not register as the current TQ, yet offers
the TQ interface, TQ 'current' checks will not work as expected and
code that relies them (TaskQueueBase::Current() and IsCurrent())
will run in unexpected ways.
Bug: webrtc:11572
Change-Id: Iab747bc474e74e6ce4f9e914cfd5b0578b19d19c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175080
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31254}
This makes it easier to maintain consistency between real time
and simulated time modes.
The RealTimeController is updated to use an explicit main thread,
this ensures that pending destruction tasks are run as the network
emulator goes out of scope.
Bug: webrtc:11255
Change-Id: Ie73ab778c78a68d7c58c0f857f14a8d8ac027c67
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/166164
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30342}
This prepares for introducing a simulated time rtc::ThreadManager
implementation that will run on a single underlying thread.
Bug: webrtc:11255
Change-Id: I793128cc0b8e649a3675914de67dfee3298b446a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165765
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30256}
Since rtc::Thread is the only class inheriting from rtc::MessageQueue
and most members of MessageQueue are public or protected the split is
not adding much value. In preparation for future cleanup, this cl merges
the two classes.
Bug: webrtc:9883
Change-Id: Ia0efb4349f66f653aa34fa4d244998f187e3ce36
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165340
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30235}
Earlier, rtc::Thread::PostTask was added as a convenient
alternative to MessageHandlers. This CL additionally adds support
for posting delayed tasks in a similar manner.
Bug: webrtc:10294
Change-Id: I0957b59ca2133a882c980bd2ad109fa03d701a16
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161740
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30069}
to generate less versions of the function template and FunctorMessageHandler helper
thus producing less binary size
Bug: None
Change-Id: Idbd6fb1e1f23b9b2dc4e4306a74ef11e74ba94cd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161044
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29962}
in support of converging on single way to run asynchronous tasks in webrtc
Bug: b/144982320
Change-Id: I200ad298136d11764a3f5c0547ebcba51aceafa0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/158782
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29896}
Since many tests rely on rtc::Thread::Current(), add an
explicit rtc::AutoThread in the main() function used by tests.
Bug: webrtc:9714
Change-Id: Id82121967c9621fe1c2945846009c48139fa57da
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/39680
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28000}
Use MessageData rather than MessageHandler to refer
to allocated storage.
That way, MessageQueue will delete storage for us if the
thread object is stopped before the Message is handled.
Leak seems triggered by the
RTCStatsIntegrationTest.GetsStatsWhileClosingPeerConnection
test.
Bug: webrtc:9714
Change-Id: I9e1255a3b6f16a763568744775ec0b3aef671227
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/136684
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27971}
This method allows asynchronously posting tasks, in the form of
functors to be invoked, on the thread represented by rtc::Thread.
This CL removes PostMessageWithFunctor(), putting the implementation of
it directly into rtc::Thread::PostTask(), and moves & updates the test
coverage to thread_unittest.cc.
Bug: webrtc:10294, webrtc:10293
Change-Id: Ic6cc3e2533a4f7aaff141aff28e9bb3908ee3c96
Reviewed-on: https://webrtc-review.googlesource.com/c/124701
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26894}
It was previously possible to escape the sandbox by calling
rtc::Thread::SetAllowBlockingCalls(true).
This CL only removes the loophole on non-Android builds, because we
still have old Android code that relies on it. We expect that code to
go away soon-ish, though.
Bug: webrtc:9987
Change-Id: Ida96400d0abe430af4c2046284795d37d64f6613
Reviewed-on: https://webrtc-review.googlesource.com/c/123523
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26792}
This CL is the result of running include-what-you-use tool on part
of the code base (audio target and dependencies) plus manual fixes.
bug: webrtc:8311
Change-Id: I277d281ce943c3ecc1bd45fd8d83055931743604
Reviewed-on: https://webrtc-review.googlesource.com/c/106280
Commit-Queue: Yves Gerey <yvesg@google.com>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25311}
This is a reland of 711a31aead
Changes since original landing:
Rename methods only used by tests, mainly via FakeClock,
MessageQueueManager::ProcessAllMessageQueues
--> ProcessAllMessageQueuesForTesting
MessageQueue::IsProcessingMessages
--> IsProcessingMessagesForTesting
Fix the handling of null rtc::Thread::Current() in
ProcessAllMessageQueuesInternal().
Add override Thread::IsProcessingMessagesForTesting() to return false
for the wrapped main thread, unless it's also the current thread. In
tests, the main thread is typically not processing any messages,
but blocked in an Event::Wait().
Original change's description:
> Explicitly wrap main thread in test_main.cc.
>
> Bug: webrtc:9714
> Change-Id: I6ee234f9a0b88b3656a683f2455c3e4b2acf0d54
> Reviewed-on: https://webrtc-review.googlesource.com/97683
> Reviewed-by: Tommi <tommi@webrtc.org>
> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
> Commit-Queue: Niels Moller <nisse@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#24560}
Bug: webrtc:9714
Change-Id: I6f022d46aaf1e28f86f09f2d68c1803b69770126
Reviewed-on: https://webrtc-review.googlesource.com/98060
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24596}
Running clang-format with chromium's style guide.
The goal is n-fold:
* providing consistency and readability (that's what code guidelines are for)
* preventing noise with presubmit checks and git cl format
* building on the previous point: making it easier to automatically fix format issues
* you name it
Please consider using git-hyper-blame to ignore this commit.
Bug: webrtc:9340
Change-Id: I694567c4cdf8cee2860958cfe82bfaf25848bb87
Reviewed-on: https://webrtc-review.googlesource.com/81185
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23660}
Thread's constructor calls DoInit, which registers itself with the
MessageQueueManager. This could result in the vptr being read before
the subclass has had a chance to modify it (for example, if another
thread happens to call MessageQueueManager::Clear at the right time).
This is exactly why there's a "DoInit" method, which is intended to be
called by the fully instantiated subclass. This was being done between
MessageQueue/Thread, but not between Thread and its subclasses.
Bug: webrtc:3911
Change-Id: I94d8855da56d9aaf22470ddca12d0b1dd5de249d
Reviewed-on: https://webrtc-review.googlesource.com/59466
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22297}
The problem with using an Event for the 'running_' flag is that a Wait() is necessary to check the value of the flag and calling Wait() means a synchronous system call. In chromium that can furthermore trigger checks on threads where IO/blocking operations aren't allowed.
Luckily, we don't really need this variable. Instead, I'm adding thread checks to make sure that the Thread class is used correctly and ensure that locking isn't needed for modifying state (no locks are there now). As long as we follow those rules, we only need to check if a thread_ variable has been set when we want to know if the thread is running or not.
Along the way, fixed some places where variables weren't being set or reset correctly.
Bug: webrtc:8596
Change-Id: I1467542416bc2ffbfefe276c460e76078a759bd9
Reviewed-on: https://webrtc-review.googlesource.com/27720
Reviewed-by: Henrik Grunell <henrikg@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21042}
These methods are platform specific and give access to member variables
from an unknown thread context (no thread check, no lock).
Since these methods aren't being used, it simplifies a minor refactoring project to simply delete them.
TBR=brandtr@webrtc.org
Bug: webrtc:8596
Change-Id: I85424820d171805dcc3d74317f0e51965402052a
Reviewed-on: https://webrtc-review.googlesource.com/28281
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#20983}
By having a unique_ptr own the callback data instead of a raw pointer,
the compiler helps us ensure that it's destroyed exactly once,
and never used after being destroyed.
(This made the callback object move-only, so I had to add support
for move-only callbacks to rtc::Thread::Invoke().)
BUG=webrtc:8111
Change-Id: Ia0804e4662e63e91e5cee18ecc3f38d2cfe8a26b
Reviewed-on: https://webrtc-review.googlesource.com/10812
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#20317}
