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
> <javascript:>> 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.
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/8d58caba-d001-43cc-8ec9-3b4f8a3c512e%40googlegroups.com.
