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 > <javascript:>> 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. Manlio > 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/16c63d5a-c5dc-41a4-ac44-fd751516c42e%40googlegroups.com.
