runtime: js-wasm builder broken due to timeout

[katiehockman]

The js-wasm builder is consistently failing after https://go-review.googlesource.com/c/go/+/199537 was merged. It's unclear exactly what exactly is going wrong from the test output, but this seems suspicious:

##### ../test/bench/go1

##### ../test

##### 
Test "test:4_10" ran over 20m0s limit (20m0.001274792s)

https://build.golang.org/log/0ebc31b62df29629efb94fc41ea07895f0b346bd

/cc @aclements @cherrymui @neelance

[neelance]

It hangs here:

go/test/goprint.go

Lines 18 to 20 in ed7e430

	for runtime.NumGoroutine() > 1 {
	time.Sleep(10*time.Millisecond)
	}

The additional goroutine that handles async events now also counts for NumGoroutine, so it never becomes 1.

@aclements @cherrymui I am not sure how to solve this the cleanest way. Do we need to adapt the test? Should the additional goroutine not count for NumGoroutine? Or should it not count as a user goroutine at all as defined by isSystemGoroutine?

[cherrymui]

In my opinion runtime.NumGoroutine should probably include the callback goroutine, as it is mostly running user code instead of runtime code. Then we should adjust the test. Unless there are a lot of code depending on the old behavior?

[cherrymui]

Related: could we start the callback goroutine lazily? Maybe at the first time a JS callback is created?

[bcmills]

If the fix for this test isn't trivial enough to apply right away, CL 199537 should be rolled back so that it does not mask other regressions on the builder. (We can roll it forward again when the fix for the test is ready.)

[neelance]

I'll have a fix ready by tomorrow. :)

[gopherbot]

Change https://golang.org/cl/200477 mentions this issue: dashboard: re-enable js/wasm test dir tests