New task queueing primitive for async tasks: TaskQueue.

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.

Committed: https://crrev.com/0c9df5e5689c8d834149ffc673c04e4216a4a774
Cr-Commit-Position: refs/heads/master@{#12561}

[tommi, 2016-04-25 08:23:50]

tommi@webrtc.org changed reviewers:
+ perkj@webrtc.org

[tommi, 2016-04-25 08:24:01]

The CQ bit was checked by tommi@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2016-04-25 08:24:10]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1919733002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1919733002/1

[tommi, 2016-04-25 08:42:22]

Fix variable destruction order in PostALot

[nisse-webrtc, 2016-04-25 08:50:49]

Maybe you want to have a look at
https://www.kernel.org/doc/Documentation/workqueue.txt

and see if there are any design ideas to borrow.

[perkj_webrtc, 2016-04-26 14:30:38]

ok- I started... Looks good.

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue.h
File webrtc/base/task_queue.h (right):

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue.h#...
webrtc/base/task_queue.h:74: class TaskQueue {
please add usage exampled in the description.

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue.h#...
webrtc/base/task_queue.h:92: void PostTaskAndReply(std::unique_ptr<QueuedTask>
task,
I vote for only the simple one until it is needed. Seems like it would be hard
to follow what is going on if you post a reply on a separate queue.

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_gc...
File webrtc/base/task_queue_gcd.cc (right):

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_gc...
webrtc/base/task_queue_gcd.cc:11: #include "webrtc/base/task_queue.h"
Can you add a note what this implement?- ie -what is gcd?

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_gc...
webrtc/base/task_queue_gcd.cc:39: queue_ = dispatch_queue_create(queue_name,
DISPATCH_QUEUE_SERIAL);
already created at line 36.

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_gc...
webrtc/base/task_queue_gcd.cc:66: TaskQueue* TaskQueue::Current() {
Can static TaskQueue::Current be made public?

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_gc...
webrtc/base/task_queue_gcd.cc:85: dispatch_async(queue_, ^{
I can read this but I have never seen ^{ before- you might want to get someone
who knows objective c to take a look. zeke?

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_gc...
webrtc/base/task_queue_gcd.cc:86: QueuedTask* t = task_ptr;  // since task_ptr
is unassignable.
Are ^{ lambdas with similar rules? 
Is task_ptr and context valid here? ie- captured by val at creation of "lambda"
?

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_gc...
webrtc/base/task_queue_gcd.cc:87: if (context->is_active) {
Does context->is_active mean that it is safe to do 

TaskQueue* q = new TaskQueue(...);
q->PostTask(...);
delete q;

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_gc...
webrtc/base/task_queue_gcd.cc:103: QueuedTask* t = task_ptr;
indentation looks weird.

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_gc...
webrtc/base/task_queue_gcd.cc:103: QueuedTask* t = task_ptr;
Humm- this is code duplication. Is there a way to avoid that?

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_li...
File webrtc/base/task_queue_libevent.cc (right):

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_li...
webrtc/base/task_queue_libevent.cc:88: std::unique_ptr<QueuedTask> task_,
reply_;
reply_ on separate line please

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_li...
webrtc/base/task_queue_libevent.cc:103: uint32_t post_time = Time32() - posted_;
Please check with nisse@ that we use the same clock methods (Time32())

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_li...
webrtc/base/task_queue_libevent.cc:155: pending_replies_.clear();
Who owns the PostAndReplyTasks?

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_li...
webrtc/base/task_queue_libevent.cc:179: // libevent isn't thread safe.  This
means that we can't use methods such
? Didn't you say you fixed that in libevent?

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_un...
File webrtc/base/task_queue_unittest.cc (right):

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_un...
webrtc/base/task_queue_unittest.cc:79: EXPECT_GE(end - start, 100u);
EXPECT_NEAR ? to check an upper bound.

[perkj_webrtc, 2016-04-28 09:58:32]

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_wi...
File webrtc/base/task_queue_win.cc (right):

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_wi...
webrtc/base/task_queue_win.cc:44: PeekMessage(&msg, NULL, WM_USER, WM_USER,
PM_NOREMOVE);
Why PeekMessage here?

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_wi...
webrtc/base/task_queue_win.cc:119: if (!PostThreadMessage(reply_thread_id,
WM_RUN_TASK, 0,
Please comment !PostThreadMessage return true.

[tommi, 2016-04-28 12:03:40]

Address comments

[tommi, 2016-04-28 12:04:02]

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue.h
File webrtc/base/task_queue.h (right):

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue.h#...
webrtc/base/task_queue.h:74: class TaskQueue {
On 2016/04/26 14:30:37, perkj_webrtc wrote:
> please add usage exampled in the description.

Done.

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue.h#...
webrtc/base/task_queue.h:92: void PostTaskAndReply(std::unique_ptr<QueuedTask>
task,
On 2016/04/26 14:30:37, perkj_webrtc wrote:
> I vote for only the simple one until it is needed. Seems like it would be hard
> to follow what is going on if you post a reply on a separate queue.

Done.

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_gc...
File webrtc/base/task_queue_gcd.cc (right):

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_gc...
webrtc/base/task_queue_gcd.cc:11: #include "webrtc/base/task_queue.h"
On 2016/04/26 14:30:37, perkj_webrtc wrote:
> Can you add a note what this implement?- ie -what is gcd?

Done.

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_gc...
webrtc/base/task_queue_gcd.cc:39: queue_ = dispatch_queue_create(queue_name,
DISPATCH_QUEUE_SERIAL);
On 2016/04/26 14:30:38, perkj_webrtc wrote:
> already created at line 36.

Doh! artefact of moving code around. Thanks for catching.

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_gc...
webrtc/base/task_queue_gcd.cc:66: TaskQueue* TaskQueue::Current() {
On 2016/04/26 14:30:37, perkj_webrtc wrote:
> Can static TaskQueue::Current be made public? 

Done.

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_gc...
webrtc/base/task_queue_gcd.cc:85: dispatch_async(queue_, ^{
On 2016/04/26 14:30:37, perkj_webrtc wrote:
> I can read this but I have never seen ^{ before- you might want to get someone
> who knows objective c to take a look. zeke? 

Good idea, however I don't think it's needed now after switching to the _f
variants of the API.

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_gc...
webrtc/base/task_queue_gcd.cc:86: QueuedTask* t = task_ptr;  // since task_ptr
is unassignable.
On 2016/04/26 14:30:37, perkj_webrtc wrote:
> Are ^{ lambdas with similar rules? 
> Is task_ptr and context valid here? ie- captured by val at creation of
"lambda"
> ? 

Yes, the rules are similar.  However, now I've removed all use of blocks in this
file.

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_gc...
webrtc/base/task_queue_gcd.cc:87: if (context->is_active) {
On 2016/04/26 14:30:37, perkj_webrtc wrote:
> Does context->is_active mean that it is safe to do 
> 
> TaskQueue* q = new TaskQueue(...);
> q->PostTask(...);
> delete q;

I think we discussed this offline today but let me know if there's a further
action I should take.

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_gc...
webrtc/base/task_queue_gcd.cc:103: QueuedTask* t = task_ptr;
On 2016/04/26 14:30:38, perkj_webrtc wrote:
> indentation looks weird.

git cl format.  However, I think that this won't be an issue after switching to
dispatch_after_f().

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_li...
File webrtc/base/task_queue_libevent.cc (right):

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_li...
webrtc/base/task_queue_libevent.cc:88: std::unique_ptr<QueuedTask> task_,
reply_;
On 2016/04/26 14:30:38, perkj_webrtc wrote:
> reply_ on separate line please

Done.

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_li...
webrtc/base/task_queue_libevent.cc:103: uint32_t post_time = Time32() - posted_;
On 2016/04/26 14:30:38, perkj_webrtc wrote:
> Please check with nisse@ that we use the same clock methods (Time32())

Yes, I'm following those changes.  I might switch this to TimeMillis() (64bit)
after rebasing.

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_li...
webrtc/base/task_queue_libevent.cc:155: pending_replies_.clear();
On 2016/04/26 14:30:38, perkj_webrtc wrote:
> Who owns the PostAndReplyTasks? 

They are stored in |pending_| or, if they can't be posted, deleted inside of
PostTask().  In any event, ownership is transferred to PostTask, same as with
other tasks.

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_li...
webrtc/base/task_queue_libevent.cc:179: // libevent isn't thread safe.  This
means that we can't use methods such
On 2016/04/26 14:30:38, perkj_webrtc wrote:
> ? Didn't you say you fixed that in libevent? 

I didn't make libevent thread safe but I did remove libevent's use of global
variables.  That made libevent usable without triggering tsan2 errors, from
multiple, single-threaded, threads. (hope that makes sense)

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_li...
webrtc/base/task_queue_libevent.cc:226: PostTask(std::move(wrapper_task));
Here is where ownership of PostAndReplyTasks is handed over to PostTask.

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_un...
File webrtc/base/task_queue_unittest.cc (right):

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_un...
webrtc/base/task_queue_unittest.cc:79: EXPECT_GE(end - start, 100u);
On 2016/04/26 14:30:38, perkj_webrtc wrote:
> EXPECT_NEAR ? to check an upper bound.

Done.

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_wi...
File webrtc/base/task_queue_win.cc (right):

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_wi...
webrtc/base/task_queue_win.cc:44: PeekMessage(&msg, NULL, WM_USER, WM_USER,
PM_NOREMOVE);
On 2016/04/28 09:58:32, perkj_webrtc wrote:
> Why PeekMessage here? 

Because no message has actually been posted.  GetMessage would hang
indefinitely.  The purpose of this call is just to create the queue on the
thread and then let the starting thread know.

https://codereview.webrtc.org/1919733002/diff/20001/webrtc/base/task_queue_wi...
webrtc/base/task_queue_win.cc:119: if (!PostThreadMessage(reply_thread_id,
WM_RUN_TASK, 0,
On 2016/04/28 09:58:32, perkj_webrtc wrote:
> Please comment !PostThreadMessage return true.

Done.

[perkj_webrtc, 2016-04-28 14:40:18]

I would like to take a last look at the linux implementation another day. But I
think this is more or less ready.

https://codereview.webrtc.org/1919733002/diff/40001/webrtc/base/task_queue.h
File webrtc/base/task_queue.h (right):

https://codereview.webrtc.org/1919733002/diff/40001/webrtc/base/task_queue.h#...
webrtc/base/task_queue.h:156: // TODO(tommi): Should we expose this variant
publicly
Remove this todo- just decide. You have a unit test that covers the use of this.

https://codereview.webrtc.org/1919733002/diff/40001/webrtc/base/task_queue_gc...
File webrtc/base/task_queue_gcd.cc (right):

https://codereview.webrtc.org/1919733002/diff/40001/webrtc/base/task_queue_gc...
webrtc/base/task_queue_gcd.cc:81: static void RunTask(void* context) {
This was easier to read :->

https://codereview.webrtc.org/1919733002/diff/40001/webrtc/base/task_queue_un...
File webrtc/base/task_queue_unittest.cc (right):

https://codereview.webrtc.org/1919733002/diff/40001/webrtc/base/task_queue_un...
webrtc/base/task_queue_unittest.cc:70:
queue.PostTask(std::unique_ptr<QueuedTask>(new CustomTask(&event)));
leaks CustomTask since Run returns false :-> See bots. Move
std::unique_ptr<QueuedTask>(new CustomTask(&event))) to outside PostTask.

https://codereview.webrtc.org/1919733002/diff/40001/webrtc/base/task_queue_un...
webrtc/base/task_queue_unittest.cc:103: EXPECT_NEAR(end - start, 200u, 100u); 
// Accept 100-300.
200?

https://codereview.webrtc.org/1919733002/diff/40001/webrtc/base/task_queue_un...
webrtc/base/task_queue_unittest.cc:140: Bind(&CheckCurrent, kReplyQueue, &event,
&reply_queue), &reply_queue);
So you made PostTaskAndReply to another queue public.

https://codereview.webrtc.org/1919733002/diff/40001/webrtc/base/task_queue_un...
webrtc/base/task_queue_unittest.cc:228: TEST(TaskQueueTest, PostALot) {
please add a better description of what this tests. Deletes pending tasks while
being destructed.

https://codereview.webrtc.org/1919733002/diff/40001/webrtc/base/task_queue_un...
webrtc/base/task_queue_unittest.cc:232: static const char kQueueName[] =
"PostALot";
why static?

[tommi, 2016-04-28 15:30:01]

Update docs and add support for cleanup lambdas

[tommi, 2016-04-28 15:30:34]

https://codereview.webrtc.org/1919733002/diff/40001/webrtc/base/task_queue.h
File webrtc/base/task_queue.h (right):

https://codereview.webrtc.org/1919733002/diff/40001/webrtc/base/task_queue.h#...
webrtc/base/task_queue.h:156: // TODO(tommi): Should we expose this variant
publicly
On 2016/04/28 14:40:17, perkj_webrtc wrote:
> Remove this todo- just decide. You have a unit test that covers the use of
this.

Removed the todo.  I meant to do that in the last patch set since we already
have a test for it and I think there will be cases where this is useful.

https://codereview.webrtc.org/1919733002/diff/40001/webrtc/base/task_queue_gc...
File webrtc/base/task_queue_gcd.cc (right):

https://codereview.webrtc.org/1919733002/diff/40001/webrtc/base/task_queue_gc...
webrtc/base/task_queue_gcd.cc:81: static void RunTask(void* context) {
On 2016/04/28 14:40:17, perkj_webrtc wrote:
> This was easier to read :->

Acknowledged.

https://codereview.webrtc.org/1919733002/diff/40001/webrtc/base/task_queue_un...
File webrtc/base/task_queue_unittest.cc (right):

https://codereview.webrtc.org/1919733002/diff/40001/webrtc/base/task_queue_un...
webrtc/base/task_queue_unittest.cc:70:
queue.PostTask(std::unique_ptr<QueuedTask>(new CustomTask(&event)));
On 2016/04/28 14:40:18, perkj_webrtc wrote:
> leaks CustomTask since Run returns false :-> See bots. Move
> std::unique_ptr<QueuedTask>(new CustomTask(&event))) to outside PostTask.

Ah, thanks. I was debating allocating the task in a certain way (on the stack)
but decided to half-way not do it.  I'll change it back to doing that even
though we shouldn't do that in production code.

https://codereview.webrtc.org/1919733002/diff/40001/webrtc/base/task_queue_un...
webrtc/base/task_queue_unittest.cc:103: EXPECT_NEAR(end - start, 200u, 100u); 
// Accept 100-300.
On 2016/04/28 14:40:18, perkj_webrtc wrote:
> 200?

Yes... I figured that because some of our trybots are *very* slow, that an ample
acceptable range would be appropriate to avoid making the test flaky.  So, to
explain 200 (since that appears to be the question):

acceptable range is: 100-300.
(100+300) / 2 == 200

so, 200 +/- 100 is allowed. :)

https://codereview.webrtc.org/1919733002/diff/40001/webrtc/base/task_queue_un...
webrtc/base/task_queue_unittest.cc:140: Bind(&CheckCurrent, kReplyQueue, &event,
&reply_queue), &reply_queue);
On 2016/04/28 14:40:17, perkj_webrtc wrote:
> So you made PostTaskAndReply to another queue public.

It was already public.  I had forgotten about this test :)

https://codereview.webrtc.org/1919733002/diff/40001/webrtc/base/task_queue_un...
webrtc/base/task_queue_unittest.cc:228: TEST(TaskQueueTest, PostALot) {
On 2016/04/28 14:40:18, perkj_webrtc wrote:
> please add a better description of what this tests. Deletes pending tasks
while
> being destructed.

Done.

I also modified the test a bit as well as supporting specifying lambdas for
doing cleanup if that's required.  This test can then use that ability to detect
if a task was dropped or processed.  On Mac, no tasks will actually get dropped
in this test (since queuing up >0xFFFF tasks, is fine).

https://codereview.webrtc.org/1919733002/diff/40001/webrtc/base/task_queue_un...
webrtc/base/task_queue_unittest.cc:232: static const char kQueueName[] =
"PostALot";
On 2016/04/28 14:40:18, perkj_webrtc wrote:
> why static?

since this is supposed to be a compile-time constant and not runtime.
An alternative would be:

const char queue_name[] = "PostALot";

but that's actual code that runs every time (i.e. not compile time and that's
also why the name would not be kQueueName).

[perkj_webrtc, 2016-04-29 07:29:44]

lgtm with the below considered.

I would like to know what you think about just removing the behaviour that
Task::Run() == false does not delete the task.

https://codereview.webrtc.org/1919733002/diff/60001/webrtc/base/task_queue_un...
File webrtc/base/task_queue_unittest.cc (right):

https://codereview.webrtc.org/1919733002/diff/60001/webrtc/base/task_queue_un...
webrtc/base/task_queue_unittest.cc:71:
queue.PostTask(std::unique_ptr<QueuedTask>(&my_task));
Would it be useful  to allow this in production code? ie-  a PostTask version
called something else that does not take std::unique_ptr? That would allow a
custom task to be reused by a caller. It might be scary since the caller have to
protect any member variables used by the caller and Run().  The same thing can
be achieved by using a CustomTask that just have a pointer as a member though so
I think I would like to answer no to my own suggestion. 

But can't the same thing be said about your reusage of Tasks in PostAndReuse.
What is the actual value of Run being able to return false to keep ownership?
ReusedTask could just as well just kept a pointer to whatever you don't want to
destroy and create a new Task for every PostTask.

https://codereview.webrtc.org/1919733002/diff/60001/webrtc/base/task_queue_un...
webrtc/base/task_queue_unittest.cc:255: 
EXPECT_EQ(0xffff +1, tasks_cleaned_up); ? Or you can't since you don't know when
the queue is actually destroyed on Mac?

[tommi, 2016-04-29 08:41:41]

Address comments+handle error reported by tsan

[tommi, 2016-04-29 09:56:24]

https://codereview.webrtc.org/1919733002/diff/60001/webrtc/base/task_queue_un...
File webrtc/base/task_queue_unittest.cc (right):

https://codereview.webrtc.org/1919733002/diff/60001/webrtc/base/task_queue_un...
webrtc/base/task_queue_unittest.cc:71:
queue.PostTask(std::unique_ptr<QueuedTask>(&my_task));
On 2016/04/29 07:29:44, perkj_webrtc wrote:
> Would it be useful  to allow this in production code?

This particular technique, posting a pointer to variable on the stack, should be
avoided.  It implies that the function that calls PostTask, needs to do some
sort of synchronization with the queue itself.  The design of TaskQueue is
intentionally made so that writing code that blocks, is hard or should feel
unnatural :)

> ie-  a PostTask version
> called something else that does not take std::unique_ptr? That would allow a
> custom task to be reused by a caller. It might be scary since the caller have
to
> protect any member variables used by the caller and Run().

I'd rather not do that.  It makes it too easy to post naked pointers.  It's
essentially offering us a base::Unretained() kind of problem even without having
to use base::Unretained.

> The same thing can
> be achieved by using a CustomTask that just have a pointer as a member though
so
> I think I would like to answer no to my own suggestion. 

Trust your instincts :)

> But can't the same thing be said about your reusage of Tasks in PostAndReuse.

It's not exactly the same.  With PostAndReuse, ownership of the task is always
held somewhere and the contract is clear.  Besides, I think that there's a
difference in going out of our way to accomplish an optimization vs being
tempted to post a raw pointer and trust that lifetime management is somehow
figured out outside of the queue.

> What is the actual value of Run being able to return false to keep ownership?
> ReusedTask could just as well just kept a pointer to whatever you don't want
to
> destroy and create a new Task for every PostTask.

The purpose is to be able to avoid allocating essentially the same thing,
repeatedly.  Having a reusable queue of buffers for example, could be very
useful and return false, could allow us to do zero heap allocations for posting
tasks. Besides the memory cost and churn, each heap allocation is also a global
lock, that's worth not grabbing.

https://codereview.webrtc.org/1919733002/diff/60001/webrtc/base/task_queue_un...
webrtc/base/task_queue_unittest.cc:255: 
On 2016/04/29 07:29:44, perkj_webrtc wrote:
> EXPECT_EQ(0xffff +1, tasks_cleaned_up); ? Or you can't since you don't know
when
> the queue is actually destroyed on Mac? 

Ah, well, that's a good point, all tasks should be cleaned up.  Done.

[tommi, 2016-04-29 09:59:00]

The CQ bit was checked by tommi@webrtc.org

[tommi, 2016-04-29 09:59:00]

The patchset sent to the CQ was uploaded after l-g-t-m from perkj@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1919733002/#ps80001 (title:
"Address comments+handle error reported by tsan")

[commit-bot: I haz the power, 2016-04-29 09:59:10]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1919733002/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1919733002/80001

[commit-bot: I haz the power, 2016-04-29 10:42:18]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-04-29 10:42:19]

Try jobs failed on following builders:
  android_arm64_rel on tryserver.webrtc (JOB_TIMED_OUT, no build URL)

[tommi, 2016-04-29 10:51:21]

The CQ bit was checked by tommi@webrtc.org

[commit-bot: I haz the power, 2016-04-29 10:51:23]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1919733002/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1919733002/80001

[commit-bot: I haz the power, 2016-04-29 11:49:10]

Committed patchset #5 (id:80001)

[tommi, 2016-04-29 13:03:06]

A revert of this CL (patchset #5 id:80001) has been created in
https://codereview.webrtc.org/1935483002/ by tommi@webrtc.org.

The reason for reverting is: Reverting this temporarily while I figure out the
issues with the Chrome on android GN debug build..

[commit-bot: I haz the power, 2016-05-01 22:01:52]

Description was changed from

==========
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.
==========

to

==========
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.

Committed: https://crrev.com/0c9df5e5689c8d834149ffc673c04e4216a4a774
Cr-Commit-Position: refs/heads/master@{#12561}
==========

[commit-bot: I haz the power, 2016-05-01 22:01:53]

Patchset 5 (id:??) landed as
https://crrev.com/0c9df5e5689c8d834149ffc673c04e4216a4a774
Cr-Commit-Position: refs/heads/master@{#12561}