os: OpenFile issue on darwin: 100% CPU on pty master read

[creack]

Go version: go version go1.9 darwin/amd64

os.OpenFile calls os.newFile with pollable always true. (

go/src/os/file_unix.go

Line 186 in 9f7fd89

return newFile(uintptr(r), name, true), nil

)

On darwin, open /dev/ptmx fails to set the non-blocking flag, however, the subsequent slaves work fine. (

go/src/os/file_unix.go

Lines 105 to 119 in 9f7fd89

	if err := f.pfd.Init("file", pollable); err != nil {
	// An error here indicates a failure to register
	// with the netpoll system. That can happen for
	// a file descriptor that is not supported by
	// epoll/kqueue; for example, disk files on
	// GNU/Linux systems. We assume that any real error
	// will show up in later I/O.
	} else if pollable {
	// We successfully registered with netpoll, so put
	// the file into nonblocking mode.
	if err := syscall.SetNonblock(fdi, true); err == nil {
	f.nonblock = true
	}
	}

)

My guess is that having the slave in non-blocking mode is the reason why read on the master takes 100% CPU.

Details of the issue: kr/pty#52
Quickfix: kr/pty#53

Is it expected always set the poller when using os.OpenFile? Maybe we should take a look at the flags and see if there is O_NONBLOCK instead of forcing it or maybe introduce a new flag to toggle the poller?

To reproduce on darwin: https://play.golang.org/p/rq8pJGL3ey

[ianlancetaylor]

On Darwin we use the poller when the operating system permits us to use kevent to pass the file descriptor to a kqueue. When there is no error there, we put the descriptor into non-blocking mode and do I/O using kqueue. It sounds like that doesn't work on Darwin for /dev/ptmx, which sounds like a bug in Darwin.

The workaround of using syscall.Open seems fine for a special purpose case like this. I'm certainly open to fixing this in the standard library if someone can figure out a good fix.