Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: os: add Number method to Signal interface #30328

0xbkt opened this issue Feb 20, 2019 · 3 comments

proposal: os: add Number method to Signal interface #30328

0xbkt opened this issue Feb 20, 2019 · 3 comments


Copy link

@0xbkt 0xbkt commented Feb 20, 2019

Signals have portable numbers identifying them on various operating systems (Plan9 excluded). But it looks like there is no direct way to retrieve these numbers from the wrapped os.Signal other than a String method which lazily looks up the name of that signal and returns it or using reflection package or type assertion. That's why I'm proposing to seal a Number(): int method to os.Signal interface and adapt current implementations to it. It will be supposed to return the original receiver provided it's an integer (or a numeric type that can be converted to integer) otherwise returning -1.

repo:^$ file:^src/syscall/ type Signal|Note
repo:^$ file:^src/syscall/ SIGINT count:1000

@gopherbot gopherbot added this to the Proposal milestone Feb 20, 2019
@gopherbot gopherbot added the Proposal label Feb 20, 2019

This comment has been minimized.

Copy link

@DeedleFake DeedleFake commented Feb 20, 2019

I'm not sure what the point is. In the definitions for the signals on Windows in

const (
    // More invented values for signals
    SIGHUP  = Signal(0x1)
    SIGINT  = Signal(0x2)
    SIGQUIT = Signal(0x3)
    SIGILL  = Signal(0x4)
    SIGTRAP = Signal(0x5)
    SIGABRT = Signal(0x6)
    SIGBUS  = Signal(0x7)
    SIGFPE  = Signal(0x8)
    SIGKILL = Signal(0x9)
    SIGSEGV = Signal(0xb)
    SIGPIPE = Signal(0xd)
    SIGALRM = Signal(0xe)
    SIGTERM = Signal(0xf)

In other words, these values are completely arbitrary. I don't think relying on them for something is a good idea. If you're going to have to treat signals differently on different systems anyways, then you may as well just check them against different values. For example:

// signal.go
c := make(chan os.Signal)

// signal_unix.go
func handleSignal(sig os.Signal) {
  switch sig {
  case os.Interrupt:
    println("UNIX interrupt.")
  case syscall.SIGHUP:

// signal_windows.go
func handleSignal(sig os.Signal) {
  switch os.Interrupt:
    println("Windows interrupt.")

This comment has been minimized.

Copy link

@ianlancetaylor ianlancetaylor commented Feb 20, 2019

If you need to deal with signal numbers, you must be running on a Unix systems. And in that case you can write sig.(syscall.Signal) to get a number.


This comment has been minimized.

Copy link

@bradfitz bradfitz commented Feb 20, 2019

Sorry, we can't expand os.Signal, as that would break the Go 1 compatibility promise. It doesn't have any unexported methods, so it's frozen:

(contrast to, say, testing.TB:

@bradfitz bradfitz closed this Feb 20, 2019
@golang golang locked and limited conversation to collaborators Feb 20, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.