Navigation Menu

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

proposal: os: (*File).SetReadDeadline and (*File).SetWriteDeadline /case: serial interface/ #22100

Closed
juliandroid opened this issue Oct 1, 2017 · 3 comments

Comments

@juliandroid
Copy link

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

go version go1.9 linux/amd64

What did you do?

	go func() {
		var buf = make([]byte, 8192)
		for {
			select {
			case <-done:
				log.Println("Quit!")
				return
			default:
				nr, _ := tty.Read(buf)
				log.Printf("Write:%s(%d)\n", string(buf[:nr]), nr)
			}
		}
	}()

Full code at https://play.golang.org/p/B4nDuMqVvk

What did you expect to see?

Goroutine to be terminated properly, i.e. done case to print Quit!

What did you see instead?

Impossible to terminate the goroutine without quitting the app or closing the TTY handle (which could be still used/needed in other gouroutine /for example to write/).

Possible workaround is by using syscall.Open, SYS_FCNTL, syscall.Read.
See full code example here: https://play.golang.org/p/k5R8RcMPwg

The biggest problem with this workaround (aside from not been idiomatic) is that if you have 50 open TTYs you have to do 50 syscall.Read calls just to find out which one caused the syscall.SIGIO

The suggestion above is part of #21834 and #18507, so I'm not going to duplicate that proposal - it is good enough, so you can close the goroutine without leaking memory and resources.

However I would like to discuss also a possible addition, like having a single channel for notification purposes with appropriate FD/TTY value sent, so you can recognize inside select statement which FD/TTY should be read.

@gopherbot gopherbot added this to the Proposal milestone Oct 1, 2017
@ianlancetaylor
Copy link
Contributor

I'm sorry, you've marked this as a proposal, but I don't understand what change you are proposing. It sounds like you are describing a problem.

@juliandroid
Copy link
Author

Ian, I'm proposing the same thing as #21834 but from perspective of the way to terminate a goroutine without closing FD. Take a look at your last comment inside #21834.

If the #21834 is implemented then select won't be blocked forever.

@ianlancetaylor
Copy link
Contributor

I'm going to close this in favor of #22114, which focuses on the key idea.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants