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}
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}
The OwningThread member of CRITICAL_SECTION is declared as having type
HANDLE but it is actually the thread's Thread ID which is a DWORD. When
doing 64-bit builds of Chromium with VS 2015 this triggers a warning
because of the suspicious conversion from 32-bit integer to 64-bit
pointer.
This change adds a cast (and some comments) to make the conversion
explicit and avoid the warning.
R=henrikg@webrtc.org
BUG=440500
Review URL: https://codereview.webrtc.org/1386183002
Cr-Commit-Position: refs/heads/master@{#10190}
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}
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}
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}
