syscall: SetNonblock doesn't work on macOS in Go 1.9.3

[davekeck]

What version of Go are you using (go version)?

go version go1.9.3 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

macOS version: 10.12.6

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Volumes/dave/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/fh/x2zwf7q53xnblct79lxf11v40000gn/T/go-build067886693=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

What did you do?

I tried to make a pipe non-blocking (with syscall.SetNonblock / unix.SetNonblock) and read from it, but the read blocks indefinitely if there's no data available:

https://play.golang.org/p/Dw_ND9gkgPm

What did you expect to see?

I expected to see the above program exit.

What did you see instead?

The above program deadlocks.

[ianlancetaylor]

This was just discussed on the mailing list, where I explained what is happening, but you left all of that out. What is the intent of opening this issue?

https://groups.google.com/d/msg/golang-nuts/uk_HozBGg_Y/nQEJRIdPBQAJ

[davekeck]

I must've misunderstood the thread. I didn't realize you were asserting that it behaves correctly, I thought you were just explaining why it behaves the way that it does.

I'll close this then, but two thoughts in case opinions can we swayed:
- it seems weird that Go 1.9 intentionally broke production code
- according to Steven Hartland from the thread, it sounds like SetNonblock behaves differently on FreeBSD than it does on macOS/Linux

That said, for my use case it's a small price to pay for making pipe.Close() safe while other goroutines are in pipe.Read() or pipe.Write().

[ianlancetaylor]

Yes, I think it works as well as possible. Once we changed pipes to be non-blocking by default, we had to break somebody. I think we made the conservative choice.