Comment 1:

That is what I see here:
C:\>test.exe
Starting server
Registering signals
Getting signal  interrupt
Finishing clean up quiting
C:\>
windows 7 
goos/goarch = windows/amd64
hg id = a9b2f3280559
So, there is no problem here. Please, give me more help to reproduce your problem. Thank
you.
Alex
PS: syscall.SIGINT has different name os.Interrupt. syscall package is os specific, you
should not use it in program that runs on many oses.

Status changed to WaitingForReply.

Comment 2 by jose.espinosa@moovweb.com:

Hey Alex,
Thanks for taking a look at this.
I compile go on the id a9b2f3280559 and still find the problem.
I dig a little bit further and I think you will be able to reproduce it if you increase
the sleep time.  Please change line 25 to "time.Sleep(50 * time.Second)" 
A arbitrary large delay is the heart of the issue.  The handling of the signal does it
is not warranty to finish thus we can't warranty that the server will clean up when
exiting.

Comment 3:

I tried with different timeouts (7, 22, 50 and 150) on both XP and Windows 7 and it runs
just fine:
c:\MinGW64\go\src>\\sob\pub\test
Starting server
Registering signals
Getting signal  interrupt
Finishing clean up quiting
c:\MinGW64\go\src>
Does it work properly for you for any Sleep values? Perhaps you could run it in debugger
or something to see what happens to the process when it "dies"?
Alex

Comment 4 by jose.espinosa@moovweb.com:

Alex,
I found the difference on our environments.  I am running it in the MinGW shell.  I try
the test case on the "cmd" shell and it works as intended.
Will dig further and post any new finding.
Alex, thanks for your help.
Jose

Comment 5:

We just add another "signal handler" to existing list of console handlers -
SetConsoleCtrlHandler
(http://msdn.microsoft.com/en-us/library/windows/desktop/ms686016%28v=vs.85%29.aspx).
Perhaps mingw console process installs its own handlers into every process it runs.
Perhaps, these are inherited somehow.
I still do not discount the possibility of bug in Go. The handler is run in its own
thread. There might be some problems there.
Alex

Comment 6 by jose.espinosa@moovweb.com:

I was able to reproduce the issue on a pure C program on the MinGW shell.
And I found this issue
http://sourceforge.net/tracker/index.php?func=detail&aid=1333217&group_id=2435&atid=102435
saying that CYGWIN does not forward the signals properly.

Comment 7:

Status changed to Retracted.