On Tue, Sep 18, 2018 at 12:42 PM, Eric Raymond <e...@thyrsus.com> wrote: > > If interruption of a function with defers is interrupted by an uncaught > signal (say, ^C from the keyboard) do its defer hooks fire? What about defer > hooks in functions up the call stack? If the interrupt happens during a > defer hook's execution, do the remaining hooks in the implied LIFO queue in > the current function fire? > > Diligent web searches have failed to produce an answer. Is this > undocumented? Unspecified? > > Suppose I catch the signal, turning it into a channel notification. Very > well; now I can call a handler, a goroutine waiting on a notification > channel. But it seems I no longer get the effect of > aborting out of the context where the signal was received unless I litter > the code with notification checks. Is this the design intent?
Signals in Go never interrupt functions. You can not use them to interrupt a goroutine. In general, there is no way to interrupt a goroutine. It can only interrupt itself, so to speak. The only way to use signals in a Go program is to use the os/signal package, which, as you suggest, turns a signal into a channel notification; see https://golang.org/pkg/os/signal . Yes, Go code normally uses explicit notification checks to see whether it should stop doing some thing. This is often in conjunction with the context package. See https://blog.golang.org/context and https://golang.org/pkg/context . 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. For more options, visit https://groups.google.com/d/optout.
