It appears that thread.cc was the only thing in the webrtc codebase that was
doing this incorrectly (platform_thread.cc, for instance, is ok).
BUG=chromium:687251
Review-Url: https://codereview.webrtc.org/2668693005
Cr-Commit-Position: refs/heads/master@{#16387}
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}
ACCESS_ON is an alias of GUARDED_BY but should take thread-like object instead of mutex,
RUN_ON is an alias of EXCLUSIVE_LOCKS_REQUIRED to annotate function always run on same
thread/task_queue
RTC_DCHECK_RUN_ON - creates an object that allows use of annotated variables and functions, and adds a run-time DCHECK given thread/queue is current.
R=tommi@webrtc.org
Review-Url: https://codereview.webrtc.org/1981893002
Cr-Commit-Position: refs/heads/master@{#12812}
But keep #including scoped_ptr.h in .h files, so as not to break
WebRTC users who expect those .h files to give them rtc::scoped_ptr.
BUG=webrtc:5520
Review-Url: https://codereview.webrtc.org/1937693002
Cr-Commit-Position: refs/heads/master@{#12581}
Moves logic of default SocketServer from MessageQueue to SocketServer
Review-Url: https://codereview.webrtc.org/1891293002
Cr-Commit-Position: refs/heads/master@{#12541}
This CL fixes a race where for Thread objects the parent MessageQueue
constructor registers the object in the MessageQueueManager even though
the Thread is not constructed completely yet. Same happens during
destruction.
BUG=webrtc:1225
Review URL: https://codereview.webrtc.org/1666863002
Cr-Commit-Position: refs/heads/master@{#11497}
* Move PlatformThread to rtc::.
* Remove ::CreateThread factory method.
* Make non-scoped_ptr from a lot of invocations.
* Make Start/Stop void.
* Remove rtc::Thread priorities, which were unused and would collide.
* Add ::IsRunning() to PlatformThread.
BUG=
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1476453002 .
Cr-Commit-Position: refs/heads/master@{#10812}
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
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
- Thread::Release() wrote a local variable on the calling thread but read it on
another thread, with no synchronization. Happily it has no non-test callers
so deleting it instead of trying to fix it (see bug for details).
- Thread::started_ similarly was racily being written to; replaced with a
running_ Event, and hid the accessor except for tests & legacy callers,
with a note about why it's a bad idea.
webrtc/base patched with:
git diff origin --relative=talk/base | patch -p1 -dwebrtc/base
followed by manual merge of 3 thunks that ran afoul of naming differences
between talk/base and webrtc/base.
BUG=3388
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/14589005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6236 4adac7df-926f-26a2-2b94-8c16560cd09d
