Reland the base->rtc_base without adding stub headers (will be
done in follow-up CL). This preserves git blame history of all files.
BUG=webrtc:7634
NOTRY=True
TBR=kwiberg@webrtc.org
Change-Id: Iea3bb6f3f67b8374c96337b63e8f5aa3e6181012
Reviewed-on: https://chromium-review.googlesource.com/554611
Reviewed-by: Henrik Kjellander <kjellander@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18821}
Will reland in two different commits to preserve git blame history.
BUG=webrtc:7634
NOTRY=True
TBR=kwiberg@webrtc.org
Change-Id: I550da8525aeb9c5b8f96338fcf1c9714f3dcdab1
Reviewed-on: https://chromium-review.googlesource.com/554610
Reviewed-by: Henrik Kjellander <kjellander@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18820}
This refactoring takes a careful approach to avoid rushing the change:
* stub headers are left in all the old locations of webrtc/base
* existing GN targets are kept and now just forward to the moved ones
using public_deps.
The only exception to the above is the base_java target and its .java files,
which were moved to webrtc/rtc_base right away since it's not possible
to use public_deps for android_library.
To avoid breaking builds, a temporary Dummy.java file was added to
the new intermediate target in webrtc/rtc_base:base_java as well to avoid
hitting a GN assert in the android_library template.
The above approach should make the transition smooth without breaking
downstream.
A helper script was created (https://codereview.webrtc.org/2879203002/)
and was run like this:
stub-headers.py -s webrtc/base -d webrtc/rtc_base -i 7634
stub-headers.py -s webrtc/base/numerics -d webrtc/rtc_base/numerics -i 7634
Fixed invalid header guards in the following files:
webrtc/base/base64.h
webrtc/base/cryptstring.h
webrtc/base/event.h
webrtc/base/flags.h
webrtc/base/httpbase.h
webrtc/base/httpcommon-inl.h
webrtc/base/httpcommon.h
webrtc/base/httpserver.h
webrtc/base/logsinks.h
webrtc/base/macutils.h
webrtc/base/nattypes.h
webrtc/base/openssladapter.h
webrtc/base/opensslstreamadapter.h
webrtc/base/pathutils.h
webrtc/base/physicalsocketserver.h
webrtc/base/proxyinfo.h
webrtc/base/sigslot.h
webrtc/base/sigslotrepeater.h
webrtc/base/socket.h
webrtc/base/socketaddresspair.h
webrtc/base/socketfactory.h
webrtc/base/stringutils.h
webrtc/base/testbase64.h
webrtc/base/testutils.h
webrtc/base/transformadapter.h
webrtc/base/win32filesystem.h
Added new header guards to:
sslroots.h
testbase64.h
BUG=webrtc:7634
NOTRY=True
NOPRESUBMIT=True
R=kwiberg@webrtc.org
Review-Url: https://codereview.webrtc.org/2877023002 .
Cr-Commit-Position: refs/heads/master@{#18816}
New task queueing primitive for async tasks: TaskQueue.
TaskQueue is a new way to asynchronously execute tasks sequentially
in a thread safe manner with minimal locking. The implementation
uses OS supported APIs to do this that are compatible with async IO
notifications from things like sockets and files.
This class is a part of rtc_base_approved, so can be used by both
the webrtc and libjingle parts of the WebRTC library. Moving forward,
we can replace rtc::Thread and webrtc::ProcessThread with this implementation.
NOTE: It should not be assumed that all tasks that execute on a TaskQueue,
run on the same thread. E.g. on Mac and iOS, we use GCD dispatch queues
which means that tasks might execute on different threads depending on
what's the most efficient thing to do.
TBR=perkj@webrtc.org,phoglund@webrtc.org
Review-Url: https://codereview.webrtc.org/1984503002
Cr-Commit-Position: refs/heads/master@{#12749}
Reason for revert:
sigh. Have to revert again as there seems to have have been some change made for pnacl and CrOS.
Original issue's description:
> Reland of New task queueing primitive for async tasks: TaskQueue. (patchset #1 id:1 of https://codereview.webrtc.org/1935483002/ )
>
> New task queueing primitive for async tasks: TaskQueue.
> TaskQueue is a new way to asynchronously execute tasks sequentially
> in a thread safe manner with minimal locking. The implementation
> uses OS supported APIs to do this that are compatible with async IO
> notifications from things like sockets and files.
>
> This class is a part of rtc_base_approved, so can be used by both
> the webrtc and libjingle parts of the WebRTC library. Moving forward,
> we can replace rtc::Thread and webrtc::ProcessThread with this implementation.
>
> NOTE: It should not be assumed that all tasks that execute on a TaskQueue,
> run on the same thread. E.g. on Mac and iOS, we use GCD dispatch queues
> which means that tasks might execute on different threads depending on
> what's the most efficient thing to do.
>
> TBR=perkj@webrtc.org
>
> Committed: https://crrev.com/65d1f2aba216d077c6d22488f03e56984aef1c68
> Cr-Commit-Position: refs/heads/master@{#12737}
TBR=perkj@webrtc.org,phoglund@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.webrtc.org/1981573002
Cr-Commit-Position: refs/heads/master@{#12738}
New task queueing primitive for async tasks: TaskQueue.
TaskQueue is a new way to asynchronously execute tasks sequentially
in a thread safe manner with minimal locking. The implementation
uses OS supported APIs to do this that are compatible with async IO
notifications from things like sockets and files.
This class is a part of rtc_base_approved, so can be used by both
the webrtc and libjingle parts of the WebRTC library. Moving forward,
we can replace rtc::Thread and webrtc::ProcessThread with this implementation.
NOTE: It should not be assumed that all tasks that execute on a TaskQueue,
run on the same thread. E.g. on Mac and iOS, we use GCD dispatch queues
which means that tasks might execute on different threads depending on
what's the most efficient thing to do.
TBR=perkj@webrtc.org
Review-Url: https://codereview.webrtc.org/1927133004
Cr-Commit-Position: refs/heads/master@{#12737}
Reason for revert:
Reverting this temporarily while I figure out the issues with the Chrome on android GN debug build.
Original issue's description:
> New task queueing primitive for async tasks: TaskQueue.
> TaskQueue is a new way to asynchronously execute tasks sequentially
> in a thread safe manner with minimal locking. The implementation
> uses OS supported APIs to do this that are compatible with async IO
> notifications from things like sockets and files.
>
> This class is a part of rtc_base_approved, so can be used by both
> the webrtc and libjingle parts of the WebRTC library. Moving forward,
> we can replace rtc::Thread and webrtc::ProcessThread with this implementation.
>
> NOTE: It should not be assumed that all tasks that execute on a TaskQueue,
> run on the same thread. E.g. on Mac and iOS, we use GCD dispatch queues
> which means that tasks might execute on different threads depending on
> what's the most efficient thing to do.
TBR=perkj@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.webrtc.org/1935483002
Cr-Commit-Position: refs/heads/master@{#12562}
TaskQueue is a new way to asynchronously execute tasks sequentially
in a thread safe manner with minimal locking. The implementation
uses OS supported APIs to do this that are compatible with async IO
notifications from things like sockets and files.
This class is a part of rtc_base_approved, so can be used by both
the webrtc and libjingle parts of the WebRTC library. Moving forward,
we can replace rtc::Thread and webrtc::ProcessThread with this implementation.
NOTE: It should not be assumed that all tasks that execute on a TaskQueue,
run on the same thread. E.g. on Mac and iOS, we use GCD dispatch queues
which means that tasks might execute on different threads depending on
what's the most efficient thing to do.
Review-Url: https://codereview.webrtc.org/1919733002
Cr-Commit-Position: refs/heads/master@{#12561}
