code review 12937043: net: make TestDeadlineRace shorter

net: make TestDeadlineRace shorter
1. Do less iterations in short mode
2. Bound number of times SetDeadline is executed

[dvyukov, 2013-08-14 17:07:10]

Hello golang-dev@googlegroups.com,

I'd like you to review this change to
https://dvyukov%40google.com@code.google.com/p/go/

[rsc, 2013-08-14 17:17:34]

LGTM

[dvyukov, 2013-08-14 17:20:15]

*** Submitted as https://code.google.com/p/go/source/detail?r=a254f0f80b6f ***

net: make TestDeadlineRace shorter
1. Do less iterations in short mode
2. Bound number of times SetDeadline is executed

R=golang-dev, rsc
CC=golang-dev
https://codereview.appspot.com/12937043

[rsc, 2013-08-14 17:46:00]

FreeBSD is still unhappy. The slow test there is TestTCPStress. Is that one of
yours?

[dvyukov, 2013-08-14 17:52:31]

On Wed, Aug 14, 2013 at 9:46 PM, <rsc@golang.org> wrote:

> FreeBSD is still unhappy. The slow test there is TestTCPStress. Is that
> one of yours?
>


In all traces on FreeBSD, there are runnable goroutines, it means it
progresses but ridiculous slowly (can't send 40K network messages in 2mins).
Sent https://codereview.appspot.com/12939043

[brainman, 2013-08-15 01:28:56]

Previous version had a problem where the test would block forever in Read, if
SetDeadline fails. Now the hanging can happens also if N loops of SetDeadline
does not unblock N Reads (can happen too, because of the race we discussed
earlier).

Both instances will fail the build, as testing package will timeout whole
package test. The former is a problem and should be recognized as such, the
later is not (this test is racy, we know about it, we don't want for test to
fail because of that).

I don't see any builder problems yet. Perhaps I am wrong here.

Alex

[dvyukov, 2013-08-15 16:40:19]

On 2013/08/15 01:28:56, brainman wrote:
> Previous version had a problem where the test would block forever in Read, if
> SetDeadline fails. Now the hanging can happens also if N loops of SetDeadline
> does not unblock N Reads (can happen too, because of the race we discussed
> earlier).

I do not understand.
A single SetDeadline can unblock any number of future Reads, the deadline is
persistent. So the last SetDeadline will unblock any remaining Reads.



> Both instances will fail the build, as testing package will timeout whole
> package test. The former is a problem and should be recognized as such, the
> later is not (this test is racy, we know about it, we don't want for test to
> fail because of that).
> 
> I don't see any builder problems yet. Perhaps I am wrong here.

[brainman, 2013-08-16 00:09:19]

> A single SetDeadline can unblock any number of future Reads, the deadline is
> persistent. So the last SetDeadline will unblock any remaining Reads.

You are right. My fears are misplaced.

Alex