On Thu, Feb 27, 2020 at 9:41 AM Robert Engels <reng...@ix.netcom.com> wrote: > > > 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?
We already have that flag: GODEBUG=noasyncpreempt=1. The discussion upthread explains that the Go wrapper for ZeroMQ should handle EINTR, and take the appropriate action such as retrying the operation when appropriate. The response to that was a bit of distraction, as it discussed generic problems with EINTR. At this point there is no reason to assume that any of those problems actually apply to using ZeroMQ. Ian > -----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/CAOyqgcWumuYUN1rity9bQEDRDNQ36eCJotJnLnUcEnd-W9miVA%40mail.gmail.com.
