On Wed, Feb 26, 2020 at 5:51 PM Michael Jones <michael.jo...@gmail.com> wrote: > > Sorry...I meant the go system signal interface could loop if desired. (Not > recommending, just saying that panicky people could be coddled if desired)
Ah, I see. Except, no, I don't. Could we really do that? Even if the signal arrived while executing some function written in C and called via cgo? Ian > On Wed, Feb 26, 2020 at 5:48 PM Ian Lance Taylor <i...@golang.org> wrote: >> >> On Wed, Feb 26, 2020 at 5:42 PM Michael Jones <michael.jo...@gmail.com> >> wrote: >> > >> > There is the BSD notion of sa_restart, a convenience to loop for the >> > caller as appropriate. >> > >> > https://www.freebsd.org/cgi/man.cgi?query=sigaction >> > >> > Go could adopt such a notion if desired. >> >> We already do. We install all signal handlers with the SA_RESTART flag set. >> >> Unfortunately if you peruse "man 7 signal" on a GNU/Linux system you >> will see a list of system calls that return EINTR even if the handler >> has SA_RESTART set. >> >> Ian >> >> > On Wed, Feb 26, 2020 at 5:14 PM Ian Lance Taylor <i...@golang.org> wrote: >> >> >> >> 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. >> > >> > >> > >> > -- >> > Michael T. Jones >> > michael.jo...@gmail.com > > -- > Michael T. Jones > michael.jo...@gmail.com -- 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/CAOyqgcW_rGLEGY2d%3Df_OacR%3D%3DSv9kPwp%2BUN8SG3N981S1quobQ%40mail.gmail.com.
