I think the difference is that a user program can block signals when working with certain devices. With Go that is not possible so the only choice is to not use Go.
Unless I am missing something else? > On Feb 27, 2020, at 9:52 AM, Ian Lance Taylor <i...@golang.org> wrote: > > 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/6D959A09-FFE8-45F7-86A0-79BC8AB1DFFB%40ix.netcom.com.
