| 12411ef40e08c5e28ccde54ab3418c96676ffcbc |
|
23-Nov-2015 |
pbos <pbos@webrtc.org> |
Move ThreadWrapper to ProcessThread in base.
Also removes all virtual methods. Permits using a thread from
rtc_base_approved (namely event tracing).
BUG=webrtc:5158
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1469013002
Cr-Commit-Position: refs/heads/master@{#10760}
/external/webrtc/webrtc/base/thread_checker_impl.h
|
| 91d6edef35e7275879c30ce16ecb8b6dc73c6e4a |
|
17-Sep-2015 |
henrikg <henrikg@webrtc.org> |
Add RTC_ prefix to (D)CHECKs and related macros.
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}
/external/webrtc/webrtc/base/thread_checker_impl.h
|
| bebc69010d09bab32f59ae110a2c181a09191f02 |
|
18-May-2015 |
Tommi <tommi@webrtc.org> |
Add platform_thread source files and move types from thread_checker_impl to there.
BUG=
R=henrika@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/52529004
Cr-Commit-Position: refs/heads/master@{#9201}
/external/webrtc/webrtc/base/thread_checker_impl.h
|
| 2eb166079130628f908f07538333130e6885c12d |
|
07-Feb-2015 |
tommi@webrtc.org <tommi@webrtc.org> |
Switch ThreadCheckerImpl over to using PlatformThreadRef.
Like PlatformThreadId, this type is borrowed from Chromium.
The difference between the two is that PlatformThreadRef is pthread_t on posix platforms.
On Windows PlatformThreadRef and PlatformThreadId are the same thing.
The reason for this switch is pretty crazy. On Chromium's "Mac 10.9 dbg" bot,
we have been seeing the following code:
ThreadCheckerImpl::ThreadCheckerImpl() : valid_thread_(CurrentThreadId()) {
fprintf(stderr, "*** valid=%d\n", valid_thread_);
valid_thread_ = CurrentThreadId();
fprintf(stderr, "*** valid after=%d\n", valid_thread_);
}
print this:
*** valid=946872320
*** valid after=5647
This is for the same thread checker instance.
What's worse is that printing out what CurrentThreadId was returning, yielded that it was always returning 5647.
After switching over to pthread_t on Mac, this stopped happening.
So, to remove the current hack, reinstate the class on Mac and take a look at the next problem, I'm switching to pthread_t.
Really looking forward to truly getting to the bottom of this.
Tbr-ing since the build is essentially broken (we can't roll).
TBR=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/37199004
Cr-Commit-Position: refs/heads/master@{#8283}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8283 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/base/thread_checker_impl.h
|
| d43bdf50c591534160daf1fc69619fe4696cf5f9 |
|
03-Feb-2015 |
tommi@webrtc.org <tommi@webrtc.org> |
Rewrite ThreadPosix.
This is the same change as already made for Windows:
https://webrtc-codereview.appspot.com/37069004/
* Remove "dead" and "alive" variables.
* Remove critical section
* Remove implementation of SetNotAlive()
* Always set thread name
* Add thread checks for correct usage.
* Changed AudioDeviceMac to create/start/stop/delete thread objects for playout and recording, inside the respective start and stop method. The reason for this is because the AudioDeviceMac instance is currently being created on one thread and the above Start/Stop methods are being called on a different thread. So, my change makes creation, start/stop, deletion of the thread objects always happen on the same thread.
I'm making CurrentThreadId() in rtc_base_approved more visible so that it can be used from there instead of inside webrtc. Down the line we will have more thread concepts in rtc_base_approved, so I put a TODO for myself to move this functionality to there once we do.
R=henrika@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/40599004
Cr-Commit-Position: refs/heads/master@{#8235}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8235 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/base/thread_checker_impl.h
|
| 04cd466bd5a05702f1f760fe9a2f4d81b2baed26 |
|
26-Jan-2015 |
tommi@webrtc.org <tommi@webrtc.org> |
Move ThreadChecker into rtc_base_approved.
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
/external/webrtc/webrtc/base/thread_checker_impl.h
|
| 1e3c5c248a5314b08765c1f629be5a4409d74013 |
|
16-Jun-2014 |
henrik.lundin@webrtc.org <henrik.lundin@webrtc.org@4adac7df-926f-26a2-2b94-8c16560cd09d> |
Importing ThreadChecker class from Chromium
The ThreadChecker class is imported/re-implemented from Chromium.
The implementation is changed to depend on WebRTC primitives.
R=andrew@webrtc.org, henrike@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/21649004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6446 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/base/thread_checker_impl.h
|