Skip to content

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

New issue
New issue
Open
Open
os: OpenFile issue on darwin: 100% CPU on pty master read#22099
Labels
NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.OS-Darwin
Milestone
Unplanned
@creack

Description

@creack
creack
opened on Oct 1, 2017

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.OS-Darwin

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions