- name(): Returns the name of the thread (useful for debugging).
- GetThreadRef(): Returns the ID of the worker thread (also useful for debugging).
- QueueApc(): This is a Windows-only, protected function that allows derived classes on Windows to queue APCs to the worker thread.
NOTRY=true
(using notry since the patch has already passed the trybots and the cq is currently stalled)
Review URL: https://codereview.webrtc.org/1908373002
Cr-Commit-Position: refs/heads/master@{#12472}
Real time clock may cause problems as they can move (even backwards) if
the clock is changed, eg updated by NTP.
Non-monotonic clocks still in use on some platform (I'm looking at you,
Apple) for timed waits, but that should be less of an issue than actual
timestamps.
BUG=webrtc:5452
Review URL: https://codereview.webrtc.org/1613013002
Cr-Commit-Position: refs/heads/master@{#11375}
* 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}
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}
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}