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

[juliandroid]

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.

[ianlancetaylor]

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]

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]

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