os: Stdin does not support SetReadDeadline

[perillo]

Please answer these questions before submitting your issue. Thanks!

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

go1.11beta2 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

GOARCH="amd64"
GOBIN="/home/manlio/.local/bin"
GOCACHE="/home/manlio/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/manlio/.local/lib/go:/home/manlio/code/src/go"
GOPROXY=""
GORACE=""
GOROOT="/home/manlio/sdk/go1.11beta2"
GOTMPDIR=""
GOTOOLDIR="/home/manlio/sdk/go1.11beta2/pkg/tool/linux_amd64"
GCCGO="gccgo"
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 -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build768901181=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I tried to call SetReadDeadline on os.Stdin but it returns an error.
I think that when Stdin is connectet to a terminal, SetReadDeadline should be supported.

The same applies (probably) to Stdout, with SetWriteDeadline.

[iamoryanmoshe]

I can't really see the value in this.. Care to give a common use case? Currently it's a function specially for net interfaces, the usual way to timeout a read from console is using goroutines.

…

On Wed, Jul 25, 2018, 02:38 Manlio Perillo ***@***.***> wrote: Please answer these questions before submitting your issue. Thanks! What version of Go are you using (go version)? go1.11beta2 linux/amd64 Does this issue reproduce with the latest release? Yes What operating system and processor architecture are you using (go env)? GOARCH="amd64" GOBIN="/home/manlio/.local/bin" GOCACHE="/home/manlio/.cache/go-build" GOEXE="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOOS="linux" GOPATH="/home/manlio/.local/lib/go:/home/manlio/code/src/go" GOPROXY="" GORACE="" GOROOT="/home/manlio/sdk/go1.11beta2" GOTMPDIR="" GOTOOLDIR="/home/manlio/sdk/go1.11beta2/pkg/tool/linux_amd64" GCCGO="gccgo" 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 -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build768901181=/tmp/go-build -gno-record-gcc-switches" What did you do? I tried to call SetReadDeadline on os.Stdin but it returns an error. I think that when Stdin is connectet to a terminal, SetReadDeadline should be supported. The same applies (*probably*) to Stdout, with SetWriteDeadline. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#26579>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AniCSOV5L8_ziMDl0WSaFWCmOFYdVmiKks5uJ6_ggaJpZM4VfNQB> .

[ianlancetaylor]

Making this change would be unwise, for somewhat tedious reasons. SetReadDeadline requires that the descriptor be in non-blocking mode, since that is how the code is implemented. If we set standard input into non-blocking mode, then if we are careless or simply unlucky the program will exit with standard input still in non-blocking mode. The shell will then carry on, with surprising and painful results.

Since standard input is just one descriptor, it's feasible to handle deadlines through a support goroutine, rather than by using SetReadDeadline directly. So I'm going to close this issue as unfortunate.

[perillo]

https://groups.google.com/forum/#!topic/golang-nuts/XDMatOviHrI

https://play.golang.org/p/6llIVJbDxQw works with a FIFO, works with a os.Pipe and it probably works with a serial device. Why SetReadDeadline should not work with os.Stdin when it is connected to a terminal?

[perillo]

Looking at the source code in file_windows.go, I suspect that, on windows, SetReadDeadline on os.Stdin works. Unfortunately I currently don't have a Windows machine available. Can someone confirm this?

[ianlancetaylor]

I don't know how to answer your question except to repeat what I already said: it could be done but it would be a bad idea. (On Unix systems, I don't know about Windows.)

[perillo]

I agree that is a very bad idea (ponylang/ponyc#205).

However if it works on Windows and not on UNIX, this should probably documented somewhere.