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 > <javascript:>> 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?
Manlio -- 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/3730faae-c75e-45fc-ae62-0668236fd35b%40googlegroups.com.
