Moves logic of default SocketServer from MessageQueue to SocketServer
Review-Url: https://codereview.webrtc.org/1891293002
Cr-Commit-Position: refs/heads/master@{#12541}
The CL prevents a data race in MessageQueue where the variable "ss_" is
modified without a lock while sometimes read inside a lock.
Also thread annotations have been added to the MessageQueue class.
This was already reviewed and landed in https://codereview.webrtc.org/1675923002/
but failed in Chromium GN builds due to sharedexclusivelock.cc not being
compiled in these builds. This changed in https://codereview.webrtc.org/1712773003/
so the reland should work fine now.
BUG=webrtc:5496
Review URL: https://codereview.webrtc.org/1729893002
Cr-Commit-Position: refs/heads/master@{#11758}
Reason for revert:
Broke chromium.webrtc.fyi bots:
https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/9891https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20GN/builds/11416
Fails with
-----
Undefined symbols for architecture x86_64:
"rtc::SharedExclusiveLock::LockShared()", referenced from:
rtc::MessageQueue::DoDestroy() in librtc_base.a(messagequeue.o)
rtc::MessageQueue::socketserver() in librtc_base.a(messagequeue.o)
rtc::MessageQueue::WakeUpSocketServer() in librtc_base.a(messagequeue.o)
rtc::MessageQueue::Quit() in librtc_base.a(messagequeue.o)
rtc::MessageQueue::Get(rtc::Message*, int, bool) in librtc_base.a(messagequeue.o)
rtc::MessageQueue::Post(rtc::MessageHandler*, unsigned int, rtc::MessageData*, bool) in librtc_base.a(messagequeue.o)
rtc::MessageQueue::DoDelayPost(int, unsigned int, rtc::MessageHandler*, unsigned int, rtc::MessageData*) in librtc_base.a(messagequeue.o)
...
"rtc::SharedExclusiveLock::UnlockShared()", referenced from:
rtc::MessageQueue::DoDestroy() in librtc_base.a(messagequeue.o)
rtc::MessageQueue::socketserver() in librtc_base.a(messagequeue.o)
rtc::MessageQueue::WakeUpSocketServer() in librtc_base.a(messagequeue.o)
rtc::MessageQueue::Quit() in librtc_base.a(messagequeue.o)
rtc::MessageQueue::Get(rtc::Message*, int, bool) in librtc_base.a(messagequeue.o)
rtc::MessageQueue::Post(rtc::MessageHandler*, unsigned int, rtc::MessageData*, bool) in librtc_base.a(messagequeue.o)
rtc::MessageQueue::DoDelayPost(int, unsigned int, rtc::MessageHandler*, unsigned int, rtc::MessageData*) in librtc_base.a(messagequeue.o)
...
"rtc::SharedExclusiveLock::SharedExclusiveLock()", referenced from:
rtc::MessageQueue::MessageQueue(rtc::SocketServer*, bool) in librtc_base.a(messagequeue.o)
ld: symbol(s) not found for architecture x86_64
-----
Looks like these are compiling without "webrtc/base/sharedexclusivelock.cc".
Original issue's description:
> Prevent data race in MessageQueue.
>
> The CL prevents a data race in MessageQueue where the variable "ss_" is
> modified without a lock while sometimes read inside a lock.
>
> Also thread annotations have been added to the MessageQueue class.
>
> BUG=webrtc:5496
>
> Committed: https://crrev.com/df88460372e7ce78c871a87774d7e6d82aac6ee3
> Cr-Commit-Position: refs/heads/master@{#11683}
TBR=ivoc@webrtc.org,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:5496
Review URL: https://codereview.webrtc.org/1714463003
Cr-Commit-Position: refs/heads/master@{#11686}
The CL prevents a data race in MessageQueue where the variable "ss_" is
modified without a lock while sometimes read inside a lock.
Also thread annotations have been added to the MessageQueue class.
BUG=webrtc:5496
Review URL: https://codereview.webrtc.org/1675923002
Cr-Commit-Position: refs/heads/master@{#11683}
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}
I wanted to use Config::Get in Chromium code, but it triggered the following
warning:
../../third_party/webrtc/common.h:89:20: error: declaration requires an exit-time destructor [-Werror,-Wexit-time-destructors]
static const T def;
^
../../third_party/webrtc/common.h:110:10: note: in instantiation of function template specialization requested here
return default_value<T>();
^
I assume we don't hit this in webrtc because the warning is disabled.
This also switches to the RTC_ prefix from the deprecated LIBJINGLE_.
Needed due to this Chromium CL:
https://codereview.chromium.org/1148843004/R=andresp@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/53459004
Cr-Commit-Position: refs/heads/master@{#9268}
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
- 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
