On Fri, Feb 28, 2020 at 8:27 AM Manlio Perillo <manlio.peri...@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? 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/CAOyqgcXMogqrgQpBBku%2BafXRiWeQ1eRONq2qQzXoexUi1-HOSw%40mail.gmail.com.
