Reason for revert:
Causes a new TSan race warning. Will reland after fixing. Note this is the same race as will be fixed by https://codereview.webrtc.org/2876273002/.
Original issue's description:
> Fixing potential AsyncInvoker deadlock that occurs for "reentrant" invocations.
>
> The deadlock occurs if the AsyncInvoker is destroyed on thread A while
> a task on thread B is running, which AsyncInvokes a task back on thread
> A.
>
> This was causing pending_invocations_ to end up negative, because
> an AsyncClosure that's never added to a thread's message queue (due to
> the "destroying_" flag) caused the count to be decremented but not
> incremented.
>
> BUG=None
>
> Review-Url: https://codereview.webrtc.org/2885143006
> Cr-Commit-Position: refs/heads/master@{#18225}
> Committed: ef37ca5fb3TBR=nisse@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=None
Review-Url: https://codereview.webrtc.org/2904543003
Cr-Commit-Position: refs/heads/master@{#18248}
The deadlock occurs if the AsyncInvoker is destroyed on thread A while
a task on thread B is running, which AsyncInvokes a task back on thread
A.
This was causing pending_invocations_ to end up negative, because
an AsyncClosure that's never added to a thread's message queue (due to
the "destroying_" flag) caused the count to be decremented but not
incremented.
BUG=None
Review-Url: https://codereview.webrtc.org/2885143006
Cr-Commit-Position: refs/heads/master@{#18225}
The crash occurs if a slot causes the very next slot in iteration order
to be disconnected.
Relanding after fixing a race condition that this CL revealed. Previously
the race resulted in an invalidated iterator, but now it will result in the
iterator being modified, so TSan catches it.
BUG=webrtc:7527
Review-Url: https://codereview.webrtc.org/2846593005
Cr-Commit-Position: refs/heads/master@{#18124}
Reason for revert:
Breaks XmppConnectionTest in Chrome.
https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_tsan_rel_ng/builds/65096
Original issue's description:
> Relanding: Fixing crash that can occur if signal is modified while firing.
>
> The crash occurs if a slot causes the very next slot in iteration order
> to be disconnected.
>
> Relanding after fixing a race condition that this CL revealed. Previously
> the race resulted in an invalidated iterator, but now it will result in the
> iterator being modified, so TSan catches it.
>
> BUG=webrtc:7527
>
> Review-Url: https://codereview.webrtc.org/2846593005
> Cr-Original-Commit-Position: refs/heads/master@{#17943}
> Committed: 961c2adf1e
> Review-Url: https://codereview.webrtc.org/2846593005
> Cr-Commit-Position: refs/heads/master@{#17965}
> Committed: fc1af01557TBR=pthatcher@webrtc.org,deadbeef@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7527
Review-Url: https://codereview.webrtc.org/2859443002
Cr-Commit-Position: refs/heads/master@{#17975}
The crash occurs if a slot causes the very next slot in iteration order
to be disconnected.
Relanding after fixing a race condition that this CL revealed. Previously
the race resulted in an invalidated iterator, but now it will result in the
iterator being modified, so TSan catches it.
BUG=webrtc:7527
Review-Url: https://codereview.webrtc.org/2846593005
Cr-Original-Commit-Position: refs/heads/master@{#17943}
Committed: 961c2adf1e
Review-Url: https://codereview.webrtc.org/2846593005
Cr-Commit-Position: refs/heads/master@{#17965}
The documentation for AsyncInvoker states that it owns the lifetime of
calls, and when its destructor is called, all in-flight calls are
cancelled or finish executing. The "cancelled" part is working, but if
a call is in the middle of executing, the destructor does *not* wait.
This is fixed by keeping a count of pending invocations, which is
decremented when a call is either cleared from a message queue or
finishes executing.
BUG=webrtc:3914, webrtc:3911
Review-Url: https://codereview.webrtc.org/2694723004
Cr-Commit-Position: refs/heads/master@{#16811}
The AsyncClosures only ever have one thing referencing them, so they
should be using std::unique_ptr to manage ownership. Maybe this code was
written before std::unique_ptr was available.
Originally reverted because it made a change to ScopedMessageData
that wasn't backwards compatible, and applications using the rtc::Thread
infrastructure may be using it.
BUG=None
NOTRY=True
Review-Url: https://codereview.webrtc.org/2689233003
Cr-Commit-Position: refs/heads/master@{#16684}
Reason for revert:
The change to messagequeue.h isn't backwards compatible. Will reland after making it backwards compatible.
Original issue's description:
> Use std::unique_ptr instead of rtc::scoped_refptr in AsyncInvoker.
>
> The AsyncClosures only ever have one thing referencing them, so they
> should be using std::unique_ptr to manage ownership. Maybe this code was
> written before std::unique_ptr was available.
>
> BUG=None
>
> Review-Url: https://codereview.webrtc.org/2689233003
> Cr-Commit-Position: refs/heads/master@{#16680}
> Committed: a5a472927bTBR=pthatcher@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=None
Review-Url: https://codereview.webrtc.org/2703613006
Cr-Commit-Position: refs/heads/master@{#16683}
The AsyncClosures only ever have one thing referencing them, so they
should be using std::unique_ptr to manage ownership. Maybe this code was
written before std::unique_ptr was available.
BUG=None
Review-Url: https://codereview.webrtc.org/2689233003
Cr-Commit-Position: refs/heads/master@{#16680}
Every message will now be traced with the location from which it was
posted, including function name, file and line number.
This CL also writes a normal LOG message when the dispatch took more
than a certain amount of time (currently 50ms).
This logging should help us identify messages that are taking
longer than expected to be dispatched.
R=pthatcher@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2019423006 .
Cr-Commit-Position: refs/heads/master@{#13104}
Any file that uses the RTC_DISALLOW_* macros should #include
"webrtc/base/constructormagic.h", but a shocking number of them don't.
This causes trouble when we try to wean files off of #including
scoped_ptr.h, since a bunch of files get their constructormagic macros
only from there.
Rather than fixing these errors one by one as they turn up, this CL
simply ensures that every file in the WebRTC tree that uses the
RTC_DISALLOW_* macros #includes "webrtc/base/constructormagic.h".
BUG=webrtc:5520
Review URL: https://codereview.webrtc.org/1917043005
Cr-Commit-Position: refs/heads/master@{#12509}
We must remove dependency on Chromium, i.e. we can't use Chromium's base/logging.h. That means we need to define these macros in WebRTC also when doing Chromium builds. And this causes redefinition.
* DISALLOW_ASSIGN -> RTC_DISALLOW_ASSIGN
* DISALLOW_COPY_AND_ASSIGN -> RTC_DISALLOW_COPY_AND_ASSIGN
* DISALLOW_IMPLICIT_CONSTRUCTORS -> RTC_DISALLOW_IMPLICIT_CONSTRUCTORS
Related CL: https://codereview.webrtc.org/1335923002/
BUG=chromium:468375
NOTRY=true
Review URL: https://codereview.webrtc.org/1345433002
Cr-Commit-Position: refs/heads/master@{#9953}
Mostly this consists of marking functions with override when
applicable, and moving function bodies from .h to .cc files.
Not inlining virtual functions with simple bodies such as
{ return false; }
strikes me as probably losing more in readability than we gain in
binary size and compilation time, but I guess it's just like any other
case where enabling a generally good warning forces us to write
slightly worse code in a couple of places.
BUG=163
R=kjellander@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47429004
Cr-Commit-Position: refs/heads/master@{#8656}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8656 4adac7df-926f-26a2-2b94-8c16560cd09d
