os: O_RDWR|O_NONBLOCK leads to blocking pipe read behavior on linux/armv7l

[aKatsuhiroMihara]

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

$ go version
go version go1.16.7 linux/386

Does this issue reproduce with the latest release?

I reproduce this behavior with go1.16.7.

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

go env Output

$ go env
GO111MODULE="auto"
GOARCH="386"
GOBIN=""
GOCACHE="/home/atmark/.cache/go-build"
GOENV="/home/atmark/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="386"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/atmark/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/atmark/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/tmp/golang/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/tmp/golang/go/pkg/tool/linux_386"
GOVCS=""
GOVERSION="go1.16.7"
GCCGO="gccgo"
GO386="sse2"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m32 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build4012975950=/tmp/go-build -gno-record-gcc-switches"

What did you do?

To I check effectiveness of unix.O_NONBLOCK, I write a program that opens a named pipe with unix.O_RDWR and unix.O_NONBLOCK. Yes, opening a named pipe with unix.O_RDWR is nonsense. This is only for checking the behavior.

When I run the program on Arm Linux, f.Read() blocks. If I replace unix.O_RDWR with unix.O_RDONLY, f.Read() reports an error. I write an equivalent on C and C's read() reports an error.

with unix.O_RDWR ... rdwr.go.txt
with unix.O_RDONLY ... rdonly.go.txt
an equivalent on C ... rdwr.c.txt

Environment of Arm linux:

atmark@armadillo:/tmp$ uname -a
Linux armadillo 4.9.133-at12 #2 SMP PREEMPT Thu Oct 31 13:20:19 JST 2019 armv7l GNU/Linux

Is this a spec or a bug?

What did you expect to see?

Like C, f.Read() should return immediately.

What did you see instead?

f.Read() blocks.

[mknyszek]

CC @ianlancetaylor via https://dev.golang.org/owners (of "os" and "x/sys/unix")

[ianlancetaylor]

In general I don't think we support passing golang.org/x/sys/unix flags to os.OpenFile. os.OpenFile is only documented as taking the flags defined in the os package, and O_NONBLOCK is not one of those flags. This is intentional, because the os package handles non-blocking itself.

If you need to pass O_NONBLOCK when opening a file, use unix.Open. Then, if you need a *os.File, call os.NewFile.

I'm going to close this issue because I don't think there is anything to change. Please comment if you disagree.