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}
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.
Alternative solutions:
* Check if we already have defined e.g. CHECK, and don't define them in that case. This makes us depend on include order in Chromium, which is not acceptable.
* Don't allow using the macros in WebRTC headers. Error prone since if someone adds it there by mistake it may compile fine, but later break if a header in added or order is changed in Chromium. That will be confusing and hard to enforce.
* Ensure that headers that are included by an embedder don't include our macros. This would require some heavy refactoring to be maintainable and enforcable.
* Changes in Chromium for this is obviously not an option.
BUG=chromium:468375
NOTRY=true
Review URL: https://codereview.webrtc.org/1335923002
Cr-Commit-Position: refs/heads/master@{#9964}
This cl uses the YV12 buffers from Java without a copy if no rotation is needed. Buffers are returned to the camera when the encoder and renderers no longer needs them.
This add a new frame type WrappedI420Buffer based in that allows for wrapping existing memory buffers and getting a notification when it is no longer used.
AndroidVideoCapturer::FrameFactory::CreateAliasedFrame wraps frame received from Java. For each wrapped frame a new reference to AndroidVideoCapturerDelegate is held to ensure that the delegate can not be destroyed until all frames have been returned.
Some overlap exist in webrtcvideoframe.cc and webrtcvideengine.cc with https://webrtc-codereview.appspot.com/47399004/ that is expected to be landed before this cl.
BUG=1128
R=glaznev@webrtc.org, magjed@webrtc.orgTBR=mflodman@webrtc.org // For changes in webrtc/common_video/video_frame_buffer
Review URL: https://webrtc-codereview.appspot.com/49459004
Cr-Commit-Position: refs/heads/master@{#8923}
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
