Skip to content
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

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

Closed
aKatsuhiroMihara opened this issue Aug 16, 2021 · 2 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@aKatsuhiroMihara
Copy link

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 mknyszek changed the title On Arm Linux, if open a file with unix.O_RDWR and unix.O_NONBLOCK, f.Read() blocks. os,x/sys/unix: O_RDWR|O_NONBLOCK leads to blocking pipe read behavior on linux/armv7l Aug 16, 2021
@mknyszek mknyszek added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Aug 16, 2021
@mknyszek mknyszek changed the title os,x/sys/unix: O_RDWR|O_NONBLOCK leads to blocking pipe read behavior on linux/armv7l os: O_RDWR|O_NONBLOCK leads to blocking pipe read behavior on linux/armv7l Aug 16, 2021
@mknyszek mknyszek added this to the Backlog milestone Aug 16, 2021
@mknyszek
Copy link
Contributor

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

@ianlancetaylor
Copy link
Contributor

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.

@golang golang locked and limited conversation to collaborators Aug 16, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

4 participants