-
Notifications
You must be signed in to change notification settings - Fork 18k
net: TCPListener fails to return errors after Close on js/wasm #50216
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Change https://golang.org/cl/372714 mentions this issue: |
In CL 372495 I cleaned up TestLimitListener so that it would not fail spuriously. However, upon further thought I realized that the original test was actually checking two different properties (steady-state saturation, and actual overload), and the cleaned-up test was only checking one of those (overload). This change adds a separate test for steady-state saturation, and makes the overload test more robust to spurious connections (which could occur, for example, if another test running on the machine accidentally dials this test's open port). The test cleanup also revealed a bad interaction with an existing bug in the js/wasm net.TCPListener implementation (filed as golang/go#50216), for which I have added a workaround in (*limitListener).Accept. For golang/go#22926 Change-Id: I727050a8254f527c7455de296ed3525b6dc90141 Reviewed-on: https://go-review.googlesource.com/c/net/+/372714 Trust: Bryan Mills <[email protected]> Run-TryBot: Bryan Mills <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]>
From further testing in CL 372714, it appears that the client ends of the buffered connections are not closed until the server ends have been returned (and closed) by If the server closes the listener without subsequently draining the |
In CL 372495 I cleaned up TestLimitListener so that it would not fail spuriously. However, upon further thought I realized that the original test was actually checking two different properties (steady-state saturation, and actual overload), and the cleaned-up test was only checking one of those (overload). This change adds a separate test for steady-state saturation, and makes the overload test more robust to spurious connections (which could occur, for example, if another test running on the machine accidentally dials this test's open port). The test cleanup also revealed a bad interaction with an existing bug in the js/wasm net.TCPListener implementation (filed as golang/go#50216), for which I have added a workaround in (*limitListener).Accept. For golang/go#22926 Change-Id: I727050a8254f527c7455de296ed3525b6dc90141 Reviewed-on: https://go-review.googlesource.com/c/net/+/372714 Trust: Bryan Mills <[email protected]> Run-TryBot: Bryan Mills <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]>
Change https://go.dev/cl/526117 mentions this issue: |
Change https://go.dev/cl/557176 mentions this issue: |
I added this map in CL 526117, but it is apparently unused. I assume that I removed all uses of it while revising that change. Updates #59718. Updates #50216. Change-Id: I8cdac39f4764d1fcc31566408304c850cf0f9374 Reviewed-on: https://go-review.googlesource.com/c/go/+/557176 Auto-Submit: Bryan Mills <[email protected]> Reviewed-by: Damien Neil <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
I added this map in CL 526117, but it is apparently unused. I assume that I removed all uses of it while revising that change. Updates golang#59718. Updates golang#50216. Change-Id: I8cdac39f4764d1fcc31566408304c850cf0f9374 Reviewed-on: https://go-review.googlesource.com/c/go/+/557176 Auto-Submit: Bryan Mills <[email protected]> Reviewed-by: Damien Neil <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
The test in https://go.dev/play/p/TO_F52CqMt8 consistently passes locally.
However, it consistently fails under
js/wasm
(CC @neelance):As far as I can tell this violates the
net.Listener
interface, which requires (emphasis mine):I noticed this via #22926.
The text was updated successfully, but these errors were encountered: