The problem is that Go designers are taking the position that any sys call should be able to be interrupted. This is invalid. For the vast majority or “unix” os an interrupt is a very rare condition and so they treat it as an error. If you issue interrupts continually you are creating an unexpected context.
> On Feb 26, 2020, at 8:39 PM, Ian Lance Taylor <i...@golang.org> wrote: > > 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. -- 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/01A4153F-6B44-4E01-AA80-63F21E1D6F39%40ix.netcom.com.
