Since http://golang.org/cl/44352, a SIGINT handler is set up by testing framework when running tests with -v.
The handler reports in-progress tests upon SIGINT, and then re-raise SIGINT.
This can cause troubles when other SIGINT handlers exist.
Minimal repro case from @neild
func TestSignals(t *testing.T) {
proc, err := os.FindProcess(os.Getpid())
if err != nil {
t.Fatal(err)
}
sigc := make(chan os.Signal, 1)
signal.Notify(sigc, os.Interrupt)
go func() {
<-sigc
signal.Stop(sigc)
}()
proc.Signal(os.Interrupt)
time.Sleep(1 * time.Second)
}
$ go test -v
=== RUN TestSignals
tests in progress: TestSignals
signal: interrupt
FAIL _/usr/local/google/home/hakim/tmp/signal 0.020s
$ go test
PASS
ok _/usr/local/google/home/hakim/tmp/signal 1.016s
This is confusing and affecting users.
@bcmills @ianlancetaylor
Since http://golang.org/cl/44352, a SIGINT handler is set up by testing framework when running tests with -v.
The handler reports in-progress tests upon SIGINT, and then re-raise SIGINT.
This can cause troubles when other SIGINT handlers exist.
Minimal repro case from @neild
func TestSignals(t *testing.T) { proc, err := os.FindProcess(os.Getpid()) if err != nil { t.Fatal(err) } sigc := make(chan os.Signal, 1) signal.Notify(sigc, os.Interrupt) go func() { <-sigc signal.Stop(sigc) }() proc.Signal(os.Interrupt) time.Sleep(1 * time.Second) }This is confusing and affecting users.
@bcmills @ianlancetaylor