On Fri, Feb 28, 2020 at 9:14 AM Manlio Perillo <manlio.peri...@gmail.com> wrote: > > On Friday, February 28, 2020 at 5:36:09 PM UTC+1, Ian Lance Taylor wrote: >> >> On Fri, Feb 28, 2020 at 8:27 AM Manlio Perillo <manlio...@gmail.com> wrote: >> > >> > On Friday, February 28, 2020 at 4:57:00 PM UTC+1, Ian Lance Taylor wrote: >> >> >> >> 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. >> >> >> > >> > But what if the program don't want to call os.Exit from the goroutine >> > handling signals, because the function calling a slow syscall want to >> > return from the function normally? >> >> To me that sounds like a theoretical argument that will never arise in >> an actual program. There is a reason to write C programs that way, >> because it's annoying to have multiple threads of execution, but there >> is no reason to ever write Go programs that way. Go programs always >> have multiple threads of execution. Just let a goroutine sit in the >> slow syscall; who cares? >> > > An user running a client program from a terminal may care. > If it takes too long to read data from a remote server, an user expects that > ^C will interrupt the program. > > However a solution is to register an atexit handler using a closure to do > some cleanup, so probably this is not an issue worth making the Go runtime > more complex.
In Go, a ^C will interrupt a program if you write code like c := make(chan os.Signal, 1) signal.Notify(c, syscall.SIGINT) go func() { <-c fmt.Printf("exiting due to ^C") os.Exit(1) }() That process is entirely independent of whether the function zmq4.Poll returns EINTR or not. 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/CAOyqgcWV_c466LwZoiznZpQMMDeB%2B%3DZeh8PM1ov5dQ1u%2ByaExg%40mail.gmail.com.