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.
