On Fri, Feb 28, 2020 at 8:13 AM Peter Kleiweg <pklei...@xs4all.nl> wrote: > > Op vrijdag 28 februari 2020 16:57:00 UTC+1 schreef Ian Lance Taylor: >> >> On Fri, Feb 28, 2020 at 7:18 AM Peter Kleiweg <pkle...@xs4all.nl> wrote: >> > >> > Op vrijdag 28 februari 2020 16:13:50 UTC+1 schreef Robert Engels: >> >> >> >> >> >> Can you clarify that a bit? Did you change the code to look for EINTR >> >> errors and then retry the system call? >> > >> > >> > Yes, I did. But as an option that must be enabled by the user. >> >> I don't understand why you're making it an option. The README >> suggests that you would not want to enable it if you want to handle >> ^C, but in Go the ^C will be delivered on a channel, presumably to a >> separate goroutine. At that point your program will either exit or do >> some other operation. If the program doesn't exit, then it's not >> going to want the interrupted system call to fail. It's going to want >> it to be retried. > > > I leave it to the end user to decide. I was inspired by this: > http://250bpm.com/blog:12
That blog post is about programming in C. Go is different. In C it makes sense to let the program decide how to handle EINTR. In Go, in my opinion, it does not. >> (As a minor side note, calls like getsockopt will never return EINTR, >> it's not necessary to retry them. But it doesn't hurt.) > > > zmq_getsockopt can return EINTR says the man page. Odd. OK. 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/CAOyqgcVQhERQ3eLk9GyquctctF8ZwH0O%3D2fdzD_O1beo1rwySA%40mail.gmail.com.
