Go programs can handle SIGQUIT
nerdatmath opened this issue · comments
This tool does not handle SIGQUIT by default because it claims that Go "doesn't seem to like handling SIGQUIT". That may have been true in prior versions of Go, but in Go 1 SIGQUIT can be handled just like any other signal. Programs run under the "go run" tool aren't able to intercept SIGQUIT, but programs compiled to an executable and run work fine. Since a goal seems to be to mimic the behavior of Unicorn and nginx, I'd suggest that SIGQUIT can be used instead of SIGTERM.
Why was this added? Handling these signals is unrelated to the function of goagain and harms portability. signal.Notify allows an arbitrary number of handlers anyway:
It is allowed to call Notify multiple times with the same channel: each call expands the set of signals sent to that channel.
If a program needs to handle other signals for other reasons, let it handle them itself, it wouldn't be more than 20 lines.
The goagain API doesn't expose the signal channel on purpose so that the API is simple: Call goagain.Wait(listener) to block until it's time to exit. The signals being handled are all also handled on purpose in order to provide the caller of goagain.Wait(listener) with all the information needed to exit as the user desires.
I'm not sure what portability concerns you're citing, either.