Use PlatformThreadRef, CurrentThreadRef and IsThreadRefEqual instead of pthread_t, pthread_self and operator== (or !=).
BUG=
Review URL: https://codereview.webrtc.org/1619153003
Cr-Commit-Position: refs/heads/master@{#11355}
According to my measurements, it's about 100x faster than the native mutex implementation in OSX. Google "OSX mutex performance" for more info.
BUG=
Review URL: https://codereview.webrtc.org/1594723003
Cr-Commit-Position: refs/heads/master@{#11352}
To ease use of WebRTC in other codebases, update some macros
to match glibc's ansidecl.h, which uses double-underscores for attributes.
NOTRY=True
Review URL: https://codereview.webrtc.org/1571653002
Cr-Commit-Position: refs/heads/master@{#11185}
Reason for revert:
Broke downstream compile step, possibly relandable when using a MSVC version that has constexpr, other than that I'm out of ideas.
.../webrtc/base/atomicops.h:71:8: note: no known conversion for argument 1 from '<brace-enclosed initializer list>' to 'const rtc::AtomicInt&'
Original issue's description:
> Reland of "Create rtc::AtomicInt POD struct."
>
> Relands https://codereview.webrtc.org/1420043008/ with brace initializers
> instead of constructors hoping that they won't introduce static
> initializers.
>
> BUG=
> R=tommi@webrtc.org
>
> Committed: https://crrev.com/84f0970d100e67a1dc4fe9a1b16b7d293302044e
> Cr-Commit-Position: refs/heads/master@{#10920}
TBR=tommi@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.webrtc.org/1505053002
Cr-Commit-Position: refs/heads/master@{#10922}
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}
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}
If srtp_create fails while adding streams, it deallocates the session
but doesn't clear the passed pointer which then could lead to a
double-free in the SrtpSession dtor.
The CL also adds locking for libsrtp initialization / shutdown.
BUG=4042
R=jiayl@webrtc.org, juberti@google.com, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47319004
Cr-Commit-Position: refs/heads/master@{#9300}
Removes FixedSizeLockFreeQueue which isn't used anymore. This enabled
moving rtc::AtomicOps to webrtc/base/atomicops.h where they should be.
BUG=4330
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/51789004
Cr-Commit-Position: refs/heads/master@{#9120}
This class is being used from both libjingle and webrtc but we recently had a regression when we added dependency on libjingle's Thread class. This cleans that up and moves the implementation of CriticalSection and helper classes into the source file.
I'm also improving debugging facilities and constness.
BUG=
R=magjed@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/51769004
Cr-Commit-Position: refs/heads/master@{#9089}
The problem we were running into on the Mac 10.9 debug bot in Chrome turned out to be good ol'fashion memory corruption. Part of webrtc was being compiled with _DEBUG, another half without it. This caused the definition of some symbols to be out of sync (notably pthread_mutex_t) and would cause code built from common.gypi, to overwrite memory allocated via common types from base/base.gypi derived code. Fun stuff to track down. This was a problem in particular with base/criticalsection.h since it's inlined into multiple object files but will have different definitions of what a mutex is.
TBR=pbos,kjellander
BUG=
Review URL: https://webrtc-codereview.appspot.com/43659004
Cr-Commit-Position: refs/heads/master@{#8646}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8646 4adac7df-926f-26a2-2b94-8c16560cd09d
Local testing indicates that the pthread_t member variable might be causing alignment problems on the Chromium bots. After landing this (and once the Chromium tree is open again), I'll try a roll again to see if this has an effect.
R=magjed@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48449004
Cr-Commit-Position: refs/heads/master@{#8644}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8644 4adac7df-926f-26a2-2b94-8c16560cd09d
To do this, I'm removing ThreadChecker's dependency on the 'Thread' class, so that the checker works with any thread and doesn't rely on TLS.
Also simplifying CriticalSection's implementation on Windows since a critical section on Windows already knows what thread currently owns the lock.
BUG=
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/40539004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8151 4adac7df-926f-26a2-2b94-8c16560cd09d
