Re-enabling socket tests that were previously flaky.

Re-enabling socket tests that were previously flaky.

It's assumed that these tests were flaky because they used a non-virtual
resource (sockets) and were being run in parallel. So this should be
fixed now that these tests are now not being run in parallel, thanks to
this CL: https://codereview.webrtc.org/1426643003

BUG=webrtc:4923
R=pthatcher@webrtc.org

Committed: https://chromium.googlesource.com/external/webrtc/+/2b3bf6b7d5d0041cf585454f3d798c4175c26e2f

[Taylor Brandstetter, 2016-05-16 18:40:59]

deadbeef@webrtc.org changed reviewers:
+ pthatcher@webrtc.org

[pthatcher1, 2016-05-16 19:57:30]

lgtm

[Taylor Brandstetter, 2016-05-17 18:19:31]

Peter, I made some more changes; do you want to review again?

[pthatcher1, 2016-05-19 18:05:40]

lgtm

https://codereview.webrtc.org/1982733002/diff/80001/webrtc/base/messagequeue.cc
File webrtc/base/messagequeue.cc (right):

https://codereview.webrtc.org/1982733002/diff/80001/webrtc/base/messagequeue....
webrtc/base/messagequeue.cc:356: return
DoDelayPost(static_cast<int>(TimeUntil(tstamp)), tstamp, phandler, id,
Could make DelayedMessage.cmsDelay_ an int64_t.   Or just delete it?

[Taylor Brandstetter, 2016-05-19 18:12:35]

https://codereview.webrtc.org/1982733002/diff/80001/webrtc/base/messagequeue.cc
File webrtc/base/messagequeue.cc (right):

https://codereview.webrtc.org/1982733002/diff/80001/webrtc/base/messagequeue....
webrtc/base/messagequeue.cc:356: return
DoDelayPost(static_cast<int>(TimeUntil(tstamp)), tstamp, phandler, id,
On 2016/05/19 18:05:39, pthatcher1 wrote:
> Could make DelayedMessage.cmsDelay_ an int64_t.   Or just delete it?

Done.

[Taylor Brandstetter, 2016-05-19 18:12:46]

The CQ bit was checked by deadbeef@webrtc.org

[Taylor Brandstetter, 2016-05-19 18:12:47]

The patchset sent to the CQ was uploaded after l-g-t-m from pthatcher@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1982733002/#ps100001 (title:
"Changing cmsDelay (only used for debugging) to int64_t")

[commit-bot: I haz the power, 2016-05-19 18:12:49]

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

[commit-bot: I haz the power, 2016-05-19 18:15:59]

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

[commit-bot: I haz the power, 2016-05-19 18:16:00]

Try jobs failed on following builders:
  android_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_dbg/builds/13456)
  android_gn_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_gn_dbg/builds/1...)
  android_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_rel/builds/13479)

[Taylor Brandstetter, 2016-05-19 18:36:04]

The CQ bit was checked by deadbeef@webrtc.org

[Taylor Brandstetter, 2016-05-19 18:36:04]

The patchset sent to the CQ was uploaded after l-g-t-m from pthatcher@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1982733002/#ps120001 (title:
"Fixing ifdefs. Using same logic as network.cc.")

[commit-bot: I haz the power, 2016-05-19 18:36:07]

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

[commit-bot: I haz the power, 2016-05-19 20:36:30]

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

[commit-bot: I haz the power, 2016-05-19 20:36:31]

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

[commit-bot: I haz the power, 2016-05-19 21:58:04]

Description was changed from

==========
Re-enabling socket tests that were previously flaky.

It's assumed that these tests were flaky because they used a non-virtual
resource (sockets) and were being run in parallel. So this should be
fixed now that these tests are now not being run in parallel, thanks to
this CL: https://codereview.webrtc.org/1426643003

BUG=webrtc:4923
==========

to

==========
Re-enabling socket tests that were previously flaky.

It's assumed that these tests were flaky because they used a non-virtual
resource (sockets) and were being run in parallel. So this should be
fixed now that these tests are now not being run in parallel, thanks to
this CL: https://codereview.webrtc.org/1426643003

BUG=webrtc:4923
R=pthatcher@webrtc.org

Committed: https://crrev.com/2b3bf6b7d5d0041cf585454f3d798c4175c26e2f
Cr-Commit-Position: refs/heads/master@{#12817}
==========

[Taylor Brandstetter, 2016-05-19 21:58:04]

Description was changed from

==========
Re-enabling socket tests that were previously flaky.

It's assumed that these tests were flaky because they used a non-virtual
resource (sockets) and were being run in parallel. So this should be
fixed now that these tests are now not being run in parallel, thanks to
this CL: https://codereview.webrtc.org/1426643003

BUG=webrtc:4923
R=pthatcher@webrtc.org

Committed: https://crrev.com/2b3bf6b7d5d0041cf585454f3d798c4175c26e2f
Cr-Commit-Position: refs/heads/master@{#12817}
==========

to

==========
Re-enabling socket tests that were previously flaky.

It's assumed that these tests were flaky because they used a non-virtual
resource (sockets) and were being run in parallel. So this should be
fixed now that these tests are now not being run in parallel, thanks to
this CL: https://codereview.webrtc.org/1426643003

BUG=webrtc:4923
R=pthatcher@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/2b3bf6b7d5d0041cf585454f3...
==========

[commit-bot: I haz the power, 2016-05-19 21:58:05]

Patchset 7 (id:??) landed as
https://crrev.com/2b3bf6b7d5d0041cf585454f3d798c4175c26e2f
Cr-Commit-Position: refs/heads/master@{#12817}

[Taylor Brandstetter, 2016-05-19 21:58:06]

Committed patchset #7 (id:120001) manually as
2b3bf6b7d5d0041cf585454f3d798c4175c26e2f (presubmit successful).