Build settings now use use_openssl in both Chromium and standalone builds. It
moves all the platform-specific SSL-related build checks to be conditioned on
this flag as appropriate.
This is to avoid colliding with Chromium's transition away from NSS.
BUG=chromium:413497
R=henrike@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/29559004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7378 4adac7df-926f-26a2-2b94-8c16560cd09d
We do not allow blocking call from the worker thread, but on Android the worker thread may stop/join a SignalThread, which hits the assert.
AssertBlockingIsAllowedOnCurrentThread is used to make sure a thread does not do Invoke, so check that in Thread::Join does not seem to add much value.
BUG=3857
R=juberti@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/24709004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7308 4adac7df-926f-26a2-2b94-8c16560cd09d
Previously if thread A->Send is called on thread B, B->ReceiveSends will be called, which enables an arbitrary thread to invoke calls on B while B is wait for A->Send to return. This caused mutliple problems like issue 3559, 3579.
The fix is to limit B->ReceiveSends to only process requests from A.
Also disallow the worker thread invoking other threads.
BUG=3559
R=juberti@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/15089004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7290 4adac7df-926f-26a2-2b94-8c16560cd09d
The synchronization access is unnecessary for rtc::Thread::WrapCurrent (called from JingleThreadWrapper) since JingleThreadWrapper never calls rtc::Thread::Stop or rtc::Thread::Join. Failing to get the access caused crashes in Chrome since rtc::Thread::Current will be NULL when rtc::Thread::WrapCurrent fails.
rtc::ThreadManager::WrapCurrentThread still requires the synchronization access, since I am not sure if the callers (e.g. the plugin) depends on it.
BUG=crbug/413853
R=juberti@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/30429004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7224 4adac7df-926f-26a2-2b94-8c16560cd09d
1) return the first global temporary and non-deprecrated ones.
2) if #1 not available, return global one.
3) if #2 not available, use ULA ipv6 as last resort.
ULA stands for unique local address. They are only useful in a private
WebRTC deployment. More detail: http://en.wikipedia.org/wiki/Unique_local_address
BUG=3808
At this point, rule #3 actually won't happen at current
implementation. The reason being that ULA address starting with 0xfc 0r 0xfd will be grouped into its own Network. The result of that is WebRTC will have one extra Network to generate candidates but the lack of rule #3 shouldn't prevent turning on IPv6 since ULA should only be tried in a close deployment anyway.
R=jiayl@webrtc.org
Committed: https://code.google.com/p/webrtc/source/detail?r=7200
Review URL: https://webrtc-codereview.appspot.com/31369004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7201 4adac7df-926f-26a2-2b94-8c16560cd09d
1) return the first global temporary and non-deprecrated ones.
2) if #1 not available, return global one.
3) if #2 not available, use ULA ipv6 as last resort.
ULA stands for unique local address. They are only useful in a private
WebRTC deployment. More detail: http://en.wikipedia.org/wiki/Unique_local_address
BUG=3808
At this point, rule #3 actually won't happen at current
implementation. The reason being that ULA address starting with 0xfc 0r 0xfd will be grouped into its own Network. The result of that is WebRTC will have one extra Network to generate candidates but the lack of rule #3 shouldn't prevent turning on IPv6 since ULA should only be tried in a close deployment anyway.
R=jiayl@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/31369004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7200 4adac7df-926f-26a2-2b94-8c16560cd09d
rtc_base drags in a bunch of unwieldly dependencies (e.g. nss and
json) not required for standalone webrtc (aka rtc/media). The root of
the problem appears to be that MessageQueue depends on a socket server.
(And since common.h -> logging.h -> thread.h -> messagequeue.h, this
dependency spreads quickly.)
This starts a new target for a "purified" subset of rtc_base. It adds
the files which are already being used, replacing the use of common.h
with checks.h. desktop_capture is a lost cause, and retains its
dependency on the full rtc_base.
The hope is that as additional components are desired they will be
cleaned and added to rtc_base_approved.
BUG=3806
R=andresp@webrtc.org, henrike@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/22649004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7188 4adac7df-926f-26a2-2b94-8c16560cd09d
This requires two fixes:
1. Use DCHECK instead of assert in ThreadChecker's unittest.
2. Activate DCHECK when DCHECK_ALWAYS_ON in enabled.
Both these modifications are in line with Chromium's implementation.
The ThreadChecker unittest was changed to use assert instead of DCHECK
on the initial import (since WebRTC did not have a DCHECK back then).
BUG=3803
TEST=local out/{Debug,Release}/rtc_unittests built with and without DCHECK_ALWAYS_ON
R=andrew@webrtc.org, pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/24569004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7178 4adac7df-926f-26a2-2b94-8c16560cd09d
In r7140 the webrtc_base target was renamed to rtc_base. This
breaks our FYI bots for rolling WebRTC in Chromium's DEPS.
By re-adding a None target named webrtc_base, this transition
should be smoother.
TBR=henrikg@webrtc.org,
TESTED=Passed build/gyp_chromium on a Chromium checkout with src/third_party/webrtc replaced by a mount like this:
cd /path/to/chromium/src
sudo mount --bind /path/to/webrtc/trunk/webrtc third_party/webrtc
Review URL: https://webrtc-codereview.appspot.com/23589004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7150 4adac7df-926f-26a2-2b94-8c16560cd09d
