I re-read your comments, and I agree that a rare error is still and error, and needs to be handled, but if it the platform is introducing lots of errors, is that the library writers issue?
Maybe an easy solution is a flag to disable the signal usage for tight-loop preemption as a "backwards compatibility" mode ? As the OP pointed out, he can't really change ZeroMQ, and this is a fairly established product, maybe more so than Go, so doesn't it make more sense that Go adapts rather than the other way around? -----Original Message----- >From: Ian Lance Taylor <i...@golang.org> >Sent: Feb 27, 2020 9:51 AM >To: Robert Engels <reng...@ix.netcom.com> >Cc: Michael Jones <michael.jo...@gmail.com>, Manlio Perillo ><manlio.peri...@gmail.com>, golang-nuts <golang-nuts@googlegroups.com> >Subject: Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go >version 1.14, no errors with earlier versions > >On Wed, Feb 26, 2020 at 8:36 PM Robert Engels <reng...@ix.netcom.com> wrote: >> >> 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. > >You're right, I do disagree. I don't think it's the Go developers who >are taking that position. It's the Unix library developers. While a >main program can make its own choices about signals, a library has to >consider the possibility that it will be included in a program that >uses signals. A rare error is still an error. Just because Go 1.14 >interrupts system calls more often doesn't mean the system calls were >not interrupted. And non-Go programs use signals too, e.g. SIGURG and >SIGIO. > >Ian > > >> > 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/CAOyqgcUdX7G1QM5o-HUVH__YUpva6X%2Bj516sqa-zrYdXu%2By-wg%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/649847589.2028.1582825289467%40wamui-lucy.atl.sa.earthlink.net.
