Reland of New task queueing primitive for async tasks: TaskQueue.

Reland of 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.

TBR=perkj@webrtc.org,phoglund@webrtc.org

Committed: https://crrev.com/c06b133b2907ea67f2c1f23488a51e0de643e9ef
Cr-Commit-Position: refs/heads/master@{#12749}

[tommi, 2016-05-14 13:00:22]

Created Reland of New task queueing primitive for async tasks: TaskQueue.

[tommi, 2016-05-14 13:01:45]

Description was changed from

==========
Reland of New task queueing primitive for async tasks: TaskQueue. (patchset #1
id:1 of https://codereview.webrtc.org/1981573002/ )

Reason for revert:
Reland of New task queueing primitive for async tasks: TaskQueue.

Original issue's description:
> Revert of New task queueing primitive for async tasks: TaskQueue. (patchset #8
id:330001 of https://codereview.webrtc.org/1927133004/ )
> 
> 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
> 
> Committed: https://crrev.com/3f90087ce8dccd0005a6c1589d34ef98486775f1
> Cr-Commit-Position: refs/heads/master@{#12738}

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

to

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

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

[tommi, 2016-05-14 13:02:14]

Description was changed from

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

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

to

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

TBR=perkj@webrtc.org,phoglund@webrtc.org
==========

[tommi, 2016-05-14 13:15:58]

Exclude nacl in GN for now due to 'config.h' issues in Chrome

[tommi, 2016-05-14 13:16:09]

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

[commit-bot: I haz the power, 2016-05-14 13:16:12]

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

[commit-bot: I haz the power, 2016-05-14 14:23:13]

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

[commit-bot: I haz the power, 2016-05-14 14:23:14]

Dry run: This issue passed the CQ dry run.

[tommi, 2016-05-14 16:02:44]

Turn off libevent if it's not available in the current build config

[tommi, 2016-05-14 16:02:58]

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

[commit-bot: I haz the power, 2016-05-14 16:03:05]

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

[commit-bot: I haz the power, 2016-05-14 16:04:15]

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

[commit-bot: I haz the power, 2016-05-14 16:04:16]

Dry run: Try jobs failed on following builders:
  ios_arm64_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_arm64_rel/builds/9716)
  ios_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_rel/builds/13652)
  mac_compile_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/mac_compile_dbg/builds/...)

[tommi, 2016-05-14 16:21:19]

Optional initialization for build_for

[tommi, 2016-05-14 16:21:26]

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

[commit-bot: I haz the power, 2016-05-14 16:21:35]

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

[commit-bot: I haz the power, 2016-05-14 17:35:28]

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

[commit-bot: I haz the power, 2016-05-14 17:35:29]

Dry run: This issue passed the CQ dry run.

[tommi, 2016-05-14 18:29:28]

per, patrik - there isn't any code change in this reland (or the previous ones),
only build config changes to address external issues.  So, landing as tbr in
webrtc and then we'll see how other builds will react.

[tommi, 2016-05-14 18:29:34]

The CQ bit was checked by tommi@webrtc.org

[commit-bot: I haz the power, 2016-05-14 18:29:45]

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

[commit-bot: I haz the power, 2016-05-14 18:31:44]

Description was changed from

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

TBR=perkj@webrtc.org,phoglund@webrtc.org
==========

to

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

TBR=perkj@webrtc.org,phoglund@webrtc.org
==========

[commit-bot: I haz the power, 2016-05-14 18:31:45]

Committed patchset #4 (id:280001)

[commit-bot: I haz the power, 2016-05-14 18:31:55]

Description was changed from

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

TBR=perkj@webrtc.org,phoglund@webrtc.org
==========

to

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

TBR=perkj@webrtc.org,phoglund@webrtc.org

Committed: https://crrev.com/c06b133b2907ea67f2c1f23488a51e0de643e9ef
Cr-Commit-Position: refs/heads/master@{#12749}
==========

[commit-bot: I haz the power, 2016-05-14 18:31:56]

Patchset 4 (id:??) landed as
https://crrev.com/c06b133b2907ea67f2c1f23488a51e0de643e9ef
Cr-Commit-Position: refs/heads/master@{#12749}

[phoglund, 2016-05-16 09:59:10]

https://codereview.webrtc.org/1984503002/diff/280001/webrtc/base/base.gyp
File webrtc/base/base.gyp (right):

https://codereview.webrtc.org/1984503002/diff/280001/webrtc/base/base.gyp#new...
webrtc/base/base.gyp:128: ['build_libevent!=1', {
Hmm, this isn't going to work since we're always forcing build_libevent to 0 in
the downstream import (we do that since we don't want line #123, we set up our
own third-party deps there).

I've landed support for libevent downstream though, so I can just try to make a
new patch where I remove this disable logic. If you still need to keep it, you
need to introduce a new variable enable_libevent_taskqueue or something so we
can separate "depend on libevent" from "use libevent at all in WebRTC."

[kjellander_webrtc, 2016-05-16 12:25:50]

kjellander@webrtc.org changed reviewers:
+ kjellander@webrtc.org

[kjellander_webrtc, 2016-05-16 12:25:51]

drive-by review.

https://codereview.webrtc.org/1984503002/diff/280001/webrtc/base/BUILD.gn
File webrtc/base/BUILD.gn (right):

https://codereview.webrtc.org/1984503002/diff/280001/webrtc/base/BUILD.gn#new...
webrtc/base/BUILD.gn:183: if (!is_win && !is_mac && !is_ios && !is_nacl) {
For GN, please introduce the same variables as for the GYP build, in
webrtc/build/webrtc.gni.

https://codereview.webrtc.org/1984503002/diff/280001/webrtc/base/BUILD.gn#new...
webrtc/base/BUILD.gn:189: sources -= [ "task_queue_libevent.cc" ]
Please only add to sources, i.e. avoid using subtraction from sources listings
(applies to GYP as well).
I've spend a fair amount of time cleaning up webrtc/base from this (see  
https://codereview.webrtc.org/1857163003 for a painful CL) and I don't want to
see it regress again. Maintenance become very cumbersome and error prone.