runtime: don't die after dumping goroutines on SIGQUIT

[rustyx]

go version go1.10.3 linux/amd64

When sending a SIGQUIT to a running Go process:

1. It dumps its goroutines to stderr (as addressed by #2516).
2. It exits.

It would have been a much more useful feature if SIGQUIT didn't kill the Go process, but only dumped the goroutines (i.e. did # 1 but not # 2).

NB: Java works that way -- a SIGQUIT dumps the threads, and then the JVM continues running normally. You can dump threads as many times as you like without killing the process.

[Freeaqingme]

quote from Wikipedia:

SIGQUIT
The SIGQUIT signal is sent to a process by its controlling terminal when the user requests that the process quit and perform a core dump.

The name sigquit really implies to me that the primary objective is to quit, the core dump is an added bonus.

Also, java isn't always the best point of reference. Java probably did a lot of things right, but may have also accumulated some behavior that's suboptimal in hindsight.

[ianlancetaylor]

Making that change at this point would break too many people's operating procedures, so we aren't going to implement it as written. I'm going to close this issue. Please comment if you disagree.

You can implement this general idea yourself using the os/signal package and the runtime.Stack function.