summaryrefslogtreecommitdiff
path: root/src/net/write_unix_test.go
diff options
context:
space:
mode:
authorIan Lance Taylor <iant@golang.org>2017-10-19 16:01:43 -0700
committerIan Lance Taylor <iant@golang.org>2017-10-20 22:26:30 +0000
commit23aad448b1e3f7c3b4ba2af90120bde91ac865b4 (patch)
treed0b60cd4e817998a50a07b9ce62b92954b110e69 /src/net/write_unix_test.go
parent4e64ee423c3a755ed31c3c98bfba98adc5995b4a (diff)
downloadgo-git-23aad448b1e3f7c3b4ba2af90120bde91ac865b4.tar.gz
runtime: for kqueue treat EVFILT_READ with EV_EOF as permitting a write
On systems that use kqueue, we always register descriptors for both EVFILT_READ and EVFILT_WRITE. On at least FreeBSD and OpenBSD, when the write end of a pipe is registered for EVFILT_READ and EVFILT_WRITE events, and the read end of the pipe is closed, kqueue reports an EVFILT_READ event with EV_EOF set, but does not report an EVFILT_WRITE event. Since the write to the pipe is waiting for an EVFILT_WRITE event, closing the read end of a pipe can cause the write end to hang rather than attempt another write which will fail with EPIPE. Fix this by treating EVFILT_READ with EV_EOF set as making both reads and writes ready to proceed. The real test for this is in CL 71770, which tests using various timeouts with pipes. Updates #22114 Change-Id: Ib23fbaaddbccd8eee77bdf18f27a7f0aa50e2742 Reviewed-on: https://go-review.googlesource.com/71973 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Diffstat (limited to 'src/net/write_unix_test.go')
-rw-r--r--src/net/write_unix_test.go66
1 files changed, 66 insertions, 0 deletions
diff --git a/src/net/write_unix_test.go b/src/net/write_unix_test.go
new file mode 100644
index 0000000000..6d8cb6a6f8
--- /dev/null
+++ b/src/net/write_unix_test.go
@@ -0,0 +1,66 @@
+// Copyright 2017 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+// +build darwin dragonfly freebsd linux netbsd openbsd solaris
+
+package net
+
+import (
+ "bytes"
+ "syscall"
+ "testing"
+ "time"
+)
+
+// Test that a client can't trigger an endless loop of write system
+// calls on the server by shutting down the write side on the client.
+// Possibility raised in the discussion of https://golang.org/cl/71973.
+func TestEndlessWrite(t *testing.T) {
+ t.Parallel()
+ c := make(chan bool)
+ server := func(cs *TCPConn) error {
+ cs.CloseWrite()
+ <-c
+ return nil
+ }
+ client := func(ss *TCPConn) error {
+ // Tell the server to return when we return.
+ defer close(c)
+
+ // Loop writing to the server. The server is not reading
+ // anything, so this will eventually block, and then time out.
+ b := bytes.Repeat([]byte{'a'}, 8192)
+ cagain := 0
+ for {
+ n, err := ss.conn.fd.pfd.WriteOnce(b)
+ if n > 0 {
+ cagain = 0
+ }
+ switch err {
+ case nil:
+ case syscall.EAGAIN:
+ if cagain == 0 {
+ // We've written enough data to
+ // start blocking. Set a deadline
+ // so that we will stop.
+ ss.SetWriteDeadline(time.Now().Add(5 * time.Millisecond))
+ }
+ cagain++
+ if cagain > 20 {
+ t.Error("looping on EAGAIN")
+ return nil
+ }
+ if err = ss.conn.fd.pfd.WaitWrite(); err != nil {
+ t.Logf("client WaitWrite: %v", err)
+ return nil
+ }
+ default:
+ // We expect to eventually get an error.
+ t.Logf("client WriteOnce: %v", err)
+ return nil
+ }
+ }
+ }
+ withTCPConnPair(t, client, server)
+}