net/http: timeout in TestIssue4191_InfiniteGetTimeout on wasip1/wasm

[bcmills]

#!watchflakes
post <- goarch == "wasm" && pkg == "net/http" && test == "TestIssue4191_InfiniteGetTimeout" && log ~ `panic: test timed out` && date < "2024-02-01"

Go version

e1c0349

Output of go env in your module/workspace:

N/A

What did you do?

#64321 (comment)

What did you see happen?

panic: test timed out after 3m0s
running tests:
	TestIssue4191_InfiniteGetTimeout/h1 (2m4s)

What did you expect to see?

All tests passing.

(attn @neild @golang/wasm)

[bcmills]

I'm able to reproduce this locally with:

GOARCH=wasm GOOS=wasip1 go test net/http -run=TestIssue4191_InfiniteGetTimeout -count=1000 -timeout=150s

I think this might be a runtime scheduler fairness issue (attn @golang/wasm @golang/runtime). In the failure log I see:

goroutine 15299 gp=0x28fa380 m=nil [runnable]:
net.(*deadlineTimer).Reset.func3()
	/home/swarming/.swarming/w/ir/x/w/goroot/src/net/net_fake.go:669 fp=0x1853fe0 sp=0x1853fd8 pc=0x21d40000
runtime.goexit({})
	/home/swarming/.swarming/w/ir/x/w/goroot/src/runtime/asm_wasm.s:434 +0x1 fp=0x1853fe8 sp=0x1853fe0 pc=0x15580001
created by time.goFunc
	/home/swarming/.swarming/w/ir/x/w/goroot/src/time/sleep.go:177 +0x5

That is the callback that is supposed to close the expired channel when the socket's deadline timer expires. However, in this test there are two other goroutines running, and at least one of them is always runnable:

• If the receive buffer is not full, then the server goroutine is runnable. (It can write to the packetQueue without blocking.)
• If the receive buffer is full, then the client goroutine is runnable. (It can read from the packetQueue without blocking.)

My hypothesis: maybe it is possible to get into a state in which the scheduler alternates between the server and client goroutines, always choosing one of those in favor of the runnable deadlineTimer goroutine?

[bcmills]

Confirmed a runtime starvation bug using a much simpler reproducer (#65178).

I think I can work around it in the net stack using a call to runtime.Gosched, although that shouldn't really be necessary in the first place.

[gopherbot]

Change https://go.dev/cl/557037 mentions this issue: net: work around runtime scheduler starvation on js and wasip1