Program finished at caught os.Interrupt into a loop

[Archos]

At caughting os.Interrupt from a loop, it runs all code of that loop
but then, the program is finished.

==
package main

import (
"fmt"
"os"
"os/signal"
)

func main() {
interrupt := make(chan os.Signal, 1)
signal.Notify(interrupt, os.Interrupt)

println("press CTRL-C")

for {
s := <-interrupt
fmt.Printf("\nCaught: signal %#v\n", s)
fmt.Println("code inner of loop")
}

/* // It faills using a select too
for {
select {
case s := <- interrupt:
fmt.Printf("\nCaught: signal %#v\n", s)
}
}
*/
fmt.Println("\ncode after of loop")
}
==
go version weekly.2012-02-14 +43cf9b39b647
linux 64 bits

[chris dollin]

You caught and ignored the interrupt signal. Wasn't that
what you wanted to do?

Chris

--
Chris "allusive" Dollin

[Jan Mercl]

On Sunday, February 19, 2012 6:06:15 PM UTC+1, Archos wrote:

At caughting os.Interrupt from a loop, it runs all code of that loop
but then, the program is finished.

... 

go version weekly.2012-02-14 +43cf9b39b647
linux 64 bits

On my machine (same Go version, Ubuntu 64b) the code works as expected:

18:17 myname@tux64:~/src/tmp$ ./tmp 

press CTRL-C

^C

Caught: signal 2

code inner of loop

^C

Caught: signal 2

code inner of loop

^C

Caught: signal 2

code inner of loop

18:18 myname@tux64:~/src/tmp$ 

[Archos]

I'm using:

$ cat /etc/lsb-release |grep DESC
DISTRIB_DESCRIPTION="Ubuntu 11.10"

$ uname -rs
Linux 3.0.0-16-generic

[Jan Mercl]

On Sunday, February 19, 2012 6:38:00 PM UTC+1, Archos wrote:

18:55 myname@tux64:~$ cat /etc/lsb-release |grep DESC ; uname -rs

DISTRIB_DESCRIPTION="Ubuntu 10.10"

Linux 2.6.35-32-generic

18:55 myname@tux64:~$ 

[DisposaBoy]

you're probably receiving that signal more than once especally if you're running as  child of something else. With your buffer set to 1, you're then missing at least one signal which you don't handle thus your program terminates

[Archos]

No, because I'd test it setting the buffer to higher values as 64.

I think that it could be by some change in Linux 3.0. Does somebody
with that kernel could test it?

[andrey mirtchovski]

> I think that it could be by some change in Linux 3.0. Does somebody
> with that kernel could test it?

blame the kernel? unlikely the source for something this basic.

$ uname -a
Linux g 3.1.5-6.fc16.x86_64 #1 SMP Thu Dec 15 16:14:44 UTC 2011 x86_64
x86_64 x86_64 GNU/Linux
$ cd /tmp
$ cat > t.go
[your code]
$ go build t.go
$ ./t

press CTRL-C
^C
Caught: signal 2
code inner of loop
^C
Caught: signal 2
code inner of loop
^C
Caught: signal 2
code inner of loop
^C
Caught: signal 2
code inner of loop
^C
Caught: signal 2
code inner of loop

^\SIGQUIT: quit
PC=0x4157c7

os/signal.loop()
/go/src/pkg/os/signal/signal_unix.go:20 +0x1c
created by os/signal.init·1
/go/src/pkg/os/signal/signal_unix.go:26 +0x2f

What is most likely happening: you're using 'go run mycode.go', so
your signal is received by the go tool, which promptly exits. your
tool gets a sigpipe (most likely) which it doesn't know how to handle.

Do this test:

$ go run ...go

then in a separate window go "ps auwx | grep a.out", once you figure
out the process id of the a.out you can send _it_ the signal and
you'll see the expected behaviour:

$ kill -2 <pid>

[Archos]

On Feb 19, 6:34 pm, andrey mirtchovski <mirtchov...@gmail.com> wrote:
> What is most likely happening: you're using 'go run mycode.go', so
> your signal is received by the go tool, which promptly exits. your
> tool gets a sigpipe (most likely) which it doesn't know how to handle.

You're right. Thanks!