On Fri, Feb 28, 2020 at 9:39 AM Manlio Perillo <manlio.peri...@gmail.com> wrote:
>
> On Friday, February 28, 2020 at 6:29:56 PM UTC+1, Ian Lance Taylor wrote:
>>
>> On Fri, Feb 28, 2020 at 9:14 AM Manlio Perillo <manlio...@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:
>> >> >
>> > [...]
>>
>> >> 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.
>>
>
> Calling os.Exit will cause the deferred functions to not be called.
Sure, there are many different ways to organize this. You're right:
you have to be aware that zmq4.Poll can block for a while, and won't
be interrupted if a signal occurs. That is exactly how every other Go
I/O function works; for example, net.Conn.Read and net.Conn.Write
behave that way. That's how Go works.
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/CAOyqgcXqj_khPxjHdqMO-xA_LzuhK_X8Rjoa_JVYNOhZ2i%3D4qg%40mail.gmail.com.
