如果本地主机连接被对等方关闭，所有其他GOOS似乎都允许写入操作而不报错，而js/wasm返回write tcp 127.0.0.1:XXX->127.0.0.1:1: Socket is not connected并显示XXX更改。
我承认这确实感觉像是应该返回错误的事情，而且我不知道是否有精确的要求要这样做，但是js作为唯一一个执行此操作的GOOS是非常不一致的，甚至在Playground中使用NaCl和其虚构的网络也不会返回错误。
这个问题出现是因为js/wasm是某些crypto/tls CL中唯一的损坏的TryBots:https://storage.googleapis.com/go-build-log/ca02321c/js-wasm_d63aa3d8.log
https://play.golang.org/p/lRhq44NJXTr(这个特定的程序实际上会在js/wasm上由于#28649而引发恐慌，但它证明了log.Print已经被到达)
/cc @neelance
4条答案
按热度按时间7lrncoxx1#
遗憾的是，在JS上实现类似TCP的字节序列全双工管道的伪实现从一开始就存在问题。此外，由于NaCl和JS上的每个实现都需要维护，这将使维护成本加倍。我有一个CL可能解决这些问题：https://go-review.googlesource.com/c/go/+/120958,但它可能会在Go 1.13或更高版本中发布。
请问您能暂时跳过这个路障测试用例吗？
jyztefdp2#
是的，我调整了测试，所以对我来说不是紧急的。请随意重新设置里程碑。
是什么阻止了那个CL?
h43kikqp3#
https://golang.org/cl/147445提到了这个问题：
crypto/tls: implement TLS 1.3 PSK authentication (server side)mzsu5hc04#
阻塞CL的原因是什么？
这只是拥塞控制；Go 1.12的计划中包含了需要运行时、操作系统和网络包的AIX和Fuchsia端口。与其他通信协议一样，拥塞控制是接收方/发送方的责任(而流量控制是接收方/发送方的责任)。