The requirements have been relaxed a little bit which should allow the test to pass on our VMs that run the tests.
BUG=6610
Review-Url: https://codereview.webrtc.org/2458713005
Cr-Commit-Position: refs/heads/master@{#14836}
This is step 2 of the plan below.
The modified plan
1. First land unmodified task_queue.h into webrtc_override in Chrome
2. Modify build files in the webrtc repo to include the task_queue.h and task_queue.cc from webrtc_overrides. This will breaks webrtc Chrome FYI.
3. Combine a roll of webrtc to Chrome and a the cl in https://codereview.chromium.org/2293913003/ into one cl.
The combined cl will roll in build files from 2 and add task_queue.cc in webrtc_overrides and build task_queue_unittest.cc as part of content_unittests to test task_queue.cc in webrtc_overrides.
4... Start using task queues in webrtc........
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/2289203002
Cr-Commit-Position: refs/heads/master@{#13983}
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}
