Adding ability to simulate EWOULDBLOCK/SignalReadyToSend.

Adding ability to simulate EWOULDBLOCK/SignalReadyToSend.

Calling VirtualSocketServer::SetSendingBlocked(true) will simulate the
network interface being blocked, and SetSendingBlocked(false) will
simulate it being unblocked, resulting in SignalReadyToSend if
appropriate.

I plan to use this to write tests for upper layers of code that deal
with EWOULDBLOCK/SignalReadyToSend.

Also doing some minor housekeeping in this CL (using RTC_DCHECK,
renaming variables, etc.).

R=pthatcher@webrtc.org, skvlad@webrtc.org

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

[skvlad, 2016-08-26 22:39:04]

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

[skvlad, 2016-08-26 22:39:04]

lgtm

https://codereview.webrtc.org/2284903002/diff/1/webrtc/base/virtualsocketserv...
File webrtc/base/virtualsocketserver.cc (right):

https://codereview.webrtc.org/2284903002/diff/1/webrtc/base/virtualsocketserv...
webrtc/base/virtualsocketserver.cc:397: // RTC_DCHECK(!local_addr_.IsAnyIP());
Do you happen to know why this is commented out? Should we perhaps delete the
line instead?

https://codereview.webrtc.org/2284903002/diff/1/webrtc/base/virtualsocketserv...
File webrtc/base/virtualsocketserver.h (right):

https://codereview.webrtc.org/2284903002/diff/1/webrtc/base/virtualsocketserv...
webrtc/base/virtualsocketserver.h:33: class VirtualSocketServer : public
SocketServer, public sigslot::has_slots<> {
Not related to the code review, more like a general question: do we have some
convention to indicate that this is test code? Otherwise it is hard for someone
who's new to the codebase to understand if the class is being used in production
or only in tests.

[Taylor Brandstetter, 2016-08-26 23:01:03]

https://codereview.webrtc.org/2284903002/diff/1/webrtc/base/virtualsocketserv...
File webrtc/base/virtualsocketserver.cc (right):

https://codereview.webrtc.org/2284903002/diff/1/webrtc/base/virtualsocketserv...
webrtc/base/virtualsocketserver.cc:397: // RTC_DCHECK(!local_addr_.IsAnyIP());
On 2016/08/26 22:39:04, skvlad wrote:
> Do you happen to know why this is commented out? Should we perhaps delete the
> line instead?

It appears this line has been commented out from the very beginning, and I can't
find an explanation. I'll just remove it.

https://codereview.webrtc.org/2284903002/diff/1/webrtc/base/virtualsocketserv...
File webrtc/base/virtualsocketserver.h (right):

https://codereview.webrtc.org/2284903002/diff/1/webrtc/base/virtualsocketserv...
webrtc/base/virtualsocketserver.h:33: class VirtualSocketServer : public
SocketServer, public sigslot::has_slots<> {
On 2016/08/26 22:39:04, skvlad wrote:
> Not related to the code review, more like a general question: do we have some
> convention to indicate that this is test code? Otherwise it is hard for
someone
> who's new to the codebase to understand if the class is being used in
production
> or only in tests.

The current convention seems to be to put test code in a "test" subdirectory.
There's one in "base", but it only has one file, dated 2016. We should move the
rest of the test code into there at some point.

[Taylor Brandstetter, 2016-08-26 23:11:16]

The CQ bit was checked by deadbeef@webrtc.org

[Taylor Brandstetter, 2016-08-26 23:11:16]

The patchset sent to the CQ was uploaded after l-g-t-m from skvlad@webrtc.org
Link to the patchset: https://codereview.webrtc.org/2284903002/#ps20001 (title:
"Removing commented-out assert")

[commit-bot: I haz the power, 2016-08-26 23:11:24]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-08-26 23:17:12]

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

[commit-bot: I haz the power, 2016-08-26 23:17:13]

Try jobs failed on following builders:
  android_rel on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_rel/builds/15889)

[Taylor Brandstetter, 2016-09-08 20:38:01]

Description was changed from

==========
Adding ability to simulate EWOULDBLOCK/SignalReadyToSend.

Calling VirtualSocketServer::SetSendingBlocked(true) will simulate the
network interface being blocked, and SetSendingBlocked(false) will
simulate it being unblocked, resulting in SignalReadyToSend if
appropriate.

I plan to use this to write tests for upper layers of code that deal
with EWOULDBLOCK/SignalReadyToSend.

Also doing some minor housekeeping in this CL (using RTC_DCHECK,
renaming variables, etc.).
==========

to

==========
Adding ability to simulate EWOULDBLOCK/SignalReadyToSend.

Calling VirtualSocketServer::SetSendingBlocked(true) will simulate the
network interface being blocked, and SetSendingBlocked(false) will
simulate it being unblocked, resulting in SignalReadyToSend if
appropriate.

I plan to use this to write tests for upper layers of code that deal
with EWOULDBLOCK/SignalReadyToSend.

Also doing some minor housekeeping in this CL (using RTC_DCHECK,
renaming variables, etc.).

TBR=pthatcher@webrtc.org
==========

[Taylor Brandstetter, 2016-09-08 20:38:01]

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

[Taylor Brandstetter, 2016-09-08 20:38:40]

Description was changed from

==========
Adding ability to simulate EWOULDBLOCK/SignalReadyToSend.

Calling VirtualSocketServer::SetSendingBlocked(true) will simulate the
network interface being blocked, and SetSendingBlocked(false) will
simulate it being unblocked, resulting in SignalReadyToSend if
appropriate.

I plan to use this to write tests for upper layers of code that deal
with EWOULDBLOCK/SignalReadyToSend.

Also doing some minor housekeeping in this CL (using RTC_DCHECK,
renaming variables, etc.).

TBR=pthatcher@webrtc.org
==========

to

==========
Adding ability to simulate EWOULDBLOCK/SignalReadyToSend.

Calling VirtualSocketServer::SetSendingBlocked(true) will simulate the
network interface being blocked, and SetSendingBlocked(false) will
simulate it being unblocked, resulting in SignalReadyToSend if
appropriate.

I plan to use this to write tests for upper layers of code that deal
with EWOULDBLOCK/SignalReadyToSend.

Also doing some minor housekeeping in this CL (using RTC_DCHECK,
renaming variables, etc.).
==========

[pthatcher1, 2016-09-09 17:15:58]

lgtm

[Taylor Brandstetter, 2016-09-09 17:20:27]

The CQ bit was checked by deadbeef@webrtc.org

[commit-bot: I haz the power, 2016-09-09 17:20:33]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-09-09 19:20:59]

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

[commit-bot: I haz the power, 2016-09-09 19:21:01]

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

[Taylor Brandstetter, 2016-09-09 20:16:28]

Description was changed from

==========
Adding ability to simulate EWOULDBLOCK/SignalReadyToSend.

Calling VirtualSocketServer::SetSendingBlocked(true) will simulate the
network interface being blocked, and SetSendingBlocked(false) will
simulate it being unblocked, resulting in SignalReadyToSend if
appropriate.

I plan to use this to write tests for upper layers of code that deal
with EWOULDBLOCK/SignalReadyToSend.

Also doing some minor housekeeping in this CL (using RTC_DCHECK,
renaming variables, etc.).
==========

to

==========
Adding ability to simulate EWOULDBLOCK/SignalReadyToSend.

Calling VirtualSocketServer::SetSendingBlocked(true) will simulate the
network interface being blocked, and SetSendingBlocked(false) will
simulate it being unblocked, resulting in SignalReadyToSend if
appropriate.

I plan to use this to write tests for upper layers of code that deal
with EWOULDBLOCK/SignalReadyToSend.

Also doing some minor housekeeping in this CL (using RTC_DCHECK,
renaming variables, etc.).

R=pthatcher@webrtc.org, skvlad@webrtc.org

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

[Taylor Brandstetter, 2016-09-09 20:16:29]

Committed patchset #2 (id:20001) manually as
e753641ef10b22eb1725a08a11491f11bf319817 (presubmit successful).

[commit-bot: I haz the power, 2016-09-09 20:16:30]

Description was changed from

==========
Adding ability to simulate EWOULDBLOCK/SignalReadyToSend.

Calling VirtualSocketServer::SetSendingBlocked(true) will simulate the
network interface being blocked, and SetSendingBlocked(false) will
simulate it being unblocked, resulting in SignalReadyToSend if
appropriate.

I plan to use this to write tests for upper layers of code that deal
with EWOULDBLOCK/SignalReadyToSend.

Also doing some minor housekeeping in this CL (using RTC_DCHECK,
renaming variables, etc.).

R=pthatcher@webrtc.org, skvlad@webrtc.org

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

to

==========
Adding ability to simulate EWOULDBLOCK/SignalReadyToSend.

Calling VirtualSocketServer::SetSendingBlocked(true) will simulate the
network interface being blocked, and SetSendingBlocked(false) will
simulate it being unblocked, resulting in SignalReadyToSend if
appropriate.

I plan to use this to write tests for upper layers of code that deal
with EWOULDBLOCK/SignalReadyToSend.

Also doing some minor housekeeping in this CL (using RTC_DCHECK,
renaming variables, etc.).

R=pthatcher@webrtc.org, skvlad@webrtc.org

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