cmd/go: unable to disable test timeout

[cpuguy83]

Please answer these questions before submitting your issue. Thanks!

1. What version of Go are you using (go version)?
   1.6
2. What operating system and processor architecture are you using (go env)?
   linux/amd64
3. What did you do?

go test timeouts are implemented in 2 ways:

There is the main timeout which just calls panic when the timeout is reached.
This timeout can be disabled when you set a value less than 1

A secondary timeout is set as a failsafe which calls SIGQUIT to dump a stacktrace and then exits.
This is set to the main timeout value + 1 minute:

go/src/cmd/go/test.go

Line 409 in 9323de3

if dt, err := time.ParseDuration(testTimeout); err == nil && dt > 0 {

If the main timeout is not > 0, it just stays at the default 10m.

1. What did you expect to see?
   The test timeout should be able to be be disabled.
2. What did you see instead?
   The secondary timeout is in place even when no timeout is set and there is no way to disable.

We use a test helper that wraps testing.T to provide its own functionality, like setup/teardown tests.
This means the entire suite uses a single testing.T. With that, means the only way to not have go kill our integration tests is to set an really high value for the timeout (which I think also defeats the purpose of the timeout to begin with).

[ianlancetaylor]

What is the difference between disabling the timeout and using a very high value? That is, why doesn't setting a very high value solve your problem?

[cpuguy83]

It works, but doesn't feel right.
And then I either have to set an insanely high value and can leave it alone or set something more inline with the time it takes to run the suite and bump it as we add new tests.

[ianlancetaylor]

What are you suggesting that we do?

Note that I would vote against anything that involves adding another option to go test. Additional knobs carry a cost, and require a corresponding benefit. That benefit needs to be more than "it feels more right."

[cpuguy83]

I agree on not adding another option. Currently the code checks if the timeout is zero and then sets the fallback if it's not.
If it is zero (or perhaps rather just explicitly set to 0) it can disable the fallback as well?

[ianlancetaylor]

I suppose that is OK with me. Want to send a patch?

[cpuguy83]

Sorry yes, I've been putting this off until I have a chance to digest the contribution process.

[gopherbot]

CL https://golang.org/cl/45631 mentions this issue.

[rsc]

I don't see any argument for changing the meaning of -timeout=0 when -timeout=1000h already does what you want and is much clearer about the effect.