On Wed, Feb 26, 2020 at 9:11 AM Manlio Perillo <manlio.peri...@gmail.com> 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: >> > >> > On Wednesday, February 26, 2020 at 3:51:54 PM UTC+1, Peter Kleiweg wrote: >> >> >> >> Op woensdag 26 februari 2020 13:05:40 UTC+1 schreef Manlio Perillo: >> >>> >> >>> On Wednesday, February 26, 2020 at 12:33:05 PM UTC+1, Peter Kleiweg >> >>> wrote: >> >>>> >> >>>> With Go version 1.14 I get a lot of errors when I run: >> >>>> >> >>>> go test -v github.com/pebbe/zmq4 >> >>>> >> >>>> I didn't see this with Go 1.13.8 or any earlier version. >> >>>> >> >>>> Is this a problem with Go 1.14, or am I doing something wrong and just >> >>>> got lucky until now? >> >>>> >> >>>> How do I debug this? The errors are different for each run. Below is a >> >>>> sample of some errors. >> >>>> Line numbers are not always accurate, because I inserted some calls to >> >>>> test.Log(). >> >>> >> >>> >> >>> The errors are probably caused by https://golang.org/doc/go1.14#runtime. >> >>> >> >>> The solution is to update zmq4 to explicitly handle interrupted system >> >>> calls. >> >> >> >> >> >> Often the program freezes before I get an interrupted system call. It >> >> hangs inside a ZeroMQ C++ library function. >> >> zmq4 is just a wrapper for ZeroMQ. I can't "fix" ZeroMQ to make it work >> >> with Go. >> >> >> >> Is there a way to stop Go from interrupting my system calls? It happens >> >> rather randomly all over the place. >> > >> > >> > 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. Ian -- 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/CAOyqgcXGcdfpPAz8t8adfqGodKPjZNxKzkTUyB0b4L1zysVFSQ%40mail.gmail.com.
