Comment 1:

That's certainly true.  Thanks for creating an issue to track this.
I don't know that we'll get to it quickly.  Signals and threads
combine for quite a bit of complexity, and then on top of that,
individual goroutines can migrate between threads.
Once the current volume dies down on the mailing list, it might
be nice to discuss what the signal handling should look like in Go.

Status changed to Thinking.

Comment 2 by gduffy:

Is creating network servers/clients not a priority for Go? SIGPIPE makes things a little 
difficult right now.

Comment 3:

SIGPIPE is handled and turns into an EPIPE returned from Write.

Owner changed to r...@golang.org.

Comment 4:

I'm sure you guys already thought of this and shot it down. But can't signals
be delivered by means of a int channel?

Comment 5:

That's one approach. We'd probably want something like:
  var Signal = make(map[int] chan int)
That way you could wait for just the particular signal(s) you want, so you could have 
a goroutine running a function looking like:
  func signalWatcher() {
    <-os.Signal[syscall.SIGHUP];  // wait for hangup signal
    // do some clean up
  }
Another approach would be a registry similar to what's found in the 'rpc' or 'http' 
package where you'd pass a function that you want called when a particular signal 
arrives. This more closely follows the traditional signal() C syscall.

Comment 6 by nathanollerenshaw:

I'm ambivalent. Either way looks good to me.

Comment 7:

Status changed to Started.

Comment 8:

Labels changed: added packagechange.

Comment 9:

This issue was closed by revision b586649.

Status changed to Fixed.

Merged into issue #-.