On Thursday, February 27, 2020 at 2:15:14 AM UTC+1, Ian Lance Taylor wrote: > > On Wed, Feb 26, 2020 at 9:11 AM Manlio Perillo <manlio...@gmail.com > <javascript:>> wrote: > > > > On Wednesday, February 26, 2020 at 4:14:38 PM UTC+1, Ian Lance Taylor > wrote: > >> > >> On Wed, Feb 26, 2020 at 7:11 AM Manlio Perillo <manlio...@gmail.com> > wrote: > > [...] > >> > > >> > > https://stackoverflow.com/questions/36040547/zeromq-how-to-react-on-different-signal-types-on-eintr > > >> > > >> > ZeroMQ may return an EINTR error , but zmq4 does not list it in > errors.go. > >> > ZeroMQ asks the caller to handle EINTR, so zmq4 should handle it > internally or return it to the caller. > >> > > >> > https://golang.org/doc/go1.14#runtime should have mentioned that not > only programs that use packages like syscall or golang.org/x/sys/unix > will see more slow system calls fail with EINTR errors, but also programs > that use Cgo. > >> > >> I don't know ZeroMQ. If the ZeroMQ calls correspond closely to system > >> calls, then it could work for them to return EINTR. In that case the > >> fix is going to be for the Go wrapper around ZeroMQ to check whether > >> the error returned is syscall.EINTR, and to retry the call if it is. > >> > > > > Unfortunately it is not that simple: > > > > http://250bpm.com/blog:12 > > https://alobbs.com/post/54503240599/close-and-eintr > > http://man7.org/linux/man-pages/man7/signal.7.html > > https://github.com/golang/go/issues/11180 > > https://www.python.org/dev/peps/pep-0475/ > > > > The second entry about close and EINTR is enlightening. > > Thanks for the links. Note that these issues don't really have > anything to do with Go. For certain system calls, you need to handle > EINTR one way or another. The Go runtime does as much as it can to > avoid these problems, but on Unix systems it is impossible to avoid > them entirely. > > I suspect people will complain whatever you do. It EINTR is returned to the caller, people will complain that they don't want to handle it. Probably they don't even know what EINTR means. If EINTR is handled by the runtime and all the exported API of the stdlib never return EINTR, some people may complain that they want to handle EINTR in their program, since only the main program can decide how to handle EINTR.
I ported the example http://250bpm.com/blog:12 to Go: https://play.golang.org/p/OkjrqtW6SdM For a server it is the right thing to do to ignore EINTR, but for an interactive client it is not. By the way, cmd/go use this pattern, closing the Interrupted channel when receiving a SIGINT or SIGQUIT signals. One thing Go can probably do is to not treat EINTR as a temporary error (as defined by Errno.Temporary method in syscall), and instead add a new method Errno.Interrupted. In this way the stdlib have more control over EINTR. Thanks Manlio -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7e2a3d16-0253-4cf8-84eb-441830086f4f%40googlegroups.com.
