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

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}

[tommi, 2016-04-29 20:28:01]

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

[tommi, 2016-04-29 20:29:19]

Description was changed from

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

Reason for revert:
Relanding

Original issue's description:
> Revert of New task queueing primitive for async tasks: TaskQueue. (patchset #5
id:80001 of https://codereview.webrtc.org/1919733002/ )
> 
> 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

TBR=perkj@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. (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
==========

[tommi, 2016-04-29 20:30:33]

Fix android debug shared chromium GN build

[tommi, 2016-04-29 20:30:42]

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

[commit-bot: I haz the power, 2016-04-29 20:30:52]

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

[commit-bot: I haz the power, 2016-04-29 22:33:16]

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

[commit-bot: I haz the power, 2016-04-29 22:33:17]

Dry run: Try jobs failed on following builders:
  win_drmemory_light on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/win_drmemory_light/buil...)

[phoglund, 2016-05-02 09:40:04]

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

[phoglund, 2016-05-02 09:40:05]

https://codereview.webrtc.org/1927133004/diff/210001/webrtc/base/base.gyp
File webrtc/base/base.gyp (right):

https://codereview.webrtc.org/1927133004/diff/210001/webrtc/base/base.gyp#new...
webrtc/base/base.gyp:121: ['OS!="win" and OS!="mac" and OS!="ios"', {
Please introduce a variable "build_libevent" which defaults to 1 in common.gypi,
and only add the dependency if that variable is 1. That is how we commonly deal
with third-party dependencies in gyp.

[tommi, 2016-05-02 13:00:26]

Add build_libevent build variable

[tommi, 2016-05-02 13:01:06]

https://codereview.webrtc.org/1927133004/diff/210001/webrtc/base/base.gyp
File webrtc/base/base.gyp (right):

https://codereview.webrtc.org/1927133004/diff/210001/webrtc/base/base.gyp#new...
webrtc/base/base.gyp:121: ['OS!="win" and OS!="mac" and OS!="ios"', {
On 2016/05/02 09:40:05, phoglund wrote:
> Please introduce a variable "build_libevent" which defaults to 1 in
common.gypi,
> and only add the dependency if that variable is 1. That is how we commonly
deal
> with third-party dependencies in gyp.

Done.

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

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

[commit-bot: I haz the power, 2016-05-02 13:01:16]

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

[commit-bot: I haz the power, 2016-05-02 13:03:48]

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

[commit-bot: I haz the power, 2016-05-02 13:03:49]

Dry run: Try jobs failed on following builders:
  android_compile_x86_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_compile_x86_dbg...)
  android_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_dbg/builds/12939)
  android_gn_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_gn_dbg/builds/1...)

[tommi, 2016-05-02 13:39:23]

On 2016/05/02 13:03:49, commit-bot: I haz the power wrote:
> Dry run: Try jobs failed on following builders:
>   android_compile_x86_dbg on tryserver.webrtc (JOB_FAILED,
>
http://build.chromium.org/p/tryserver.webrtc/builders/android_compile_x86_dbg...)
>   android_dbg on tryserver.webrtc (JOB_FAILED,
>
http://build.chromium.org/p/tryserver.webrtc/builders/android_dbg/builds/12939)
>   android_gn_dbg on tryserver.webrtc (JOB_FAILED,
>
http://build.chromium.org/p/tryserver.webrtc/builders/android_gn_dbg/builds/1...)

nailed it.

[tommi, 2016-05-02 13:47:56]

Fix gyp gaffe

[tommi, 2016-05-02 13:55:54]

Fix GN gaffe!

[tommi, 2016-05-02 13:56:29]

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

[commit-bot: I haz the power, 2016-05-02 13:56:34]

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

[commit-bot: I haz the power, 2016-05-02 14:19:37]

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

[commit-bot: I haz the power, 2016-05-02 14:19:38]

Dry run: Try jobs failed on following builders:
  linux_asan on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_asan/builds/14380)

[tommi, 2016-05-02 17:19:39]

Rebase

[tommi, 2016-05-04 21:46:00]

Rebase

[tommi, 2016-05-10 10:19:25]

Rebase

[tommi, 2016-05-13 17:33:27]

The CQ bit was checked by tommi@webrtc.org

[commit-bot: I haz the power, 2016-05-13 17:33:30]

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

[commit-bot: I haz the power, 2016-05-13 20:05:02]

Description was changed from

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

to

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

[commit-bot: I haz the power, 2016-05-13 20:05:03]

Committed patchset #8 (id:330001)

[commit-bot: I haz the power, 2016-05-13 20:05:09]

Description was changed from

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

to

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

[commit-bot: I haz the power, 2016-05-13 20:05:10]

Patchset 8 (id:??) landed as
https://crrev.com/65d1f2aba216d077c6d22488f03e56984aef1c68
Cr-Commit-Position: refs/heads/master@{#12737}

[tommi, 2016-05-13 21:33:19]

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

The reason for reverting is: sigh.  Have to revert again as there seems to have
have been some change made for pnacl and CrOS..