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

os/signal: No access to the siginfo_t struct #9764

Open
quentinmit opened this issue Feb 3, 2015 · 16 comments
Open

os/signal: No access to the siginfo_t struct #9764

quentinmit opened this issue Feb 3, 2015 · 16 comments
Assignees
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FeatureRequest help wanted
Milestone

Comments

@quentinmit
Copy link
Contributor

The siginfo_t struct that is delivered with signals contains various useful information about the signal. In some cases, this information is necessary to implement the kernel API of various features. For example, fcntl(F_SETLEASE) requires that your process receive a SIGIO when the lock is broken, and the si_fd field in the siginfo_t struct tells you what filehandle the kernel is notifying your process about.

Please provide an interface that will allow Go code to access the information in the siginfo_t struct.

@rsc
Copy link
Contributor

rsc commented Apr 10, 2015

We'd need to figure out a nice, portable API to do this.

@dothebart
Copy link

https://man7.org/linux/man-pages/man2/sigaction.2.html is the referenced Structure.
Since its quiet usefull for debugging to log i.e. which process sent you a signal, it would be really great to see support for this.

@ianlancetaylor
Copy link
Contributor

The stress here is on portable. The man page you cite is Linux-specific.

@LordRusk
Copy link

Rather than needing a super portable way to do this, could we simply add access to it through /x/sys/unix because of its specificity? It's really dragging down a project of mine to not have access to this struct in any way.

@ianlancetaylor
Copy link
Contributor

We still need a nice, portable API. I don't see how using x/sys/unix helps. I don't have any ideas for an API.

@LordRusk
Copy link

Please correct me if I'm mistaken, but it seems the SignalfdSigInfo struct is equivalent to siginfo_t - only missing a few fields, including si_sigval which is what I need. Syscall is deprecated in favor of /x/sys for OS specificity, that is why I bring it up. Not sure why si_sigval wasn't included, or what it would take to add it, but with this in mind I'm not sure why we'd need a 'portable API' for this.

/x/sys/unix/.SignalfdInfo & siginfo_t comparison

@ianlancetaylor
Copy link
Contributor

I agree what we don't need a portable API for the exact definition of siginfo_t. We can do something similar to how fs.FileInfo has a Sys method that returns a system-specific data structure.

What we need is a portable API for how to access that system-specific information.

@LordRusk
Copy link

SignalfdSiginfo is not an equivalent of siginfo_t and isn't supposed to be, that's my bad.

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 7, 2022
@mitar
Copy link
Contributor

mitar commented May 28, 2023

os.ProcessState has method Sys which returns:

Sys returns system-dependent exit information about the process. Convert it to the appropriate underlying type, such as syscall.WaitStatus on Unix, to access its contents.

I think solution here could be similar. I think os.Signal could have Sys method which return a system-dependent signal information about the signal. On unix, something equivalent to siginfo_t.

This could be done with additional interface:

type Sys interface {
    Sys() any
}

And some implementations of the Signal interface could also implement Sys interface. For example, syscall.Signal type could also implement Sys interface on unix.

@ianlancetaylor
Copy link
Contributor

Unfortunately I don't see how that suggestion would work given our existing choices. We've already promised that on Unix systems, the implementation of the os.Signal is syscall.Signal. And syscall.Signal is an int, and the value of that int is just the signal number. So while we could indeed add a Sys method to syscall.Signal, there is no place to store the pointer that we need.

@mitar
Copy link
Contributor

mitar commented May 29, 2023

Hm, signal.Notify uses os.Signal type and does not promise that on unix the implementation will be syscall.Signal? Only os.Signal documentation mentions that on unix there exist an implementation called syscall.Signal which satisfies the interface. Maybe this is stretching it a bit, but I do not find that this mean that the only implementation of os.Signal ever used on unix will be syscall.Signal, only that that implementation is one which does satisfy the interface on unix?

If this is not possible, then maybe signal package should have NotifySys function which instead of sending os.Signal to the channel if would be sending any. But this looks sad to me because to me the whole point of having the os.Signal interface is that you can get different implementations of this interface in the future.

@ianlancetaylor
Copy link
Contributor

I don't see any ambiguity in the docs for os.Signal (https://pkg.go.dev/os#Signal). I think they say clearly that on Unix systems an os.Signal is a syscall.Signal. More to the point, we've not only documented it but I'm confident that existing programs rely on it. We would need a really good reason to break that.

@mitar
Copy link
Contributor

mitar commented May 29, 2023

So what about func NotifySys(c chan<- any, sig ...os.Signal)?

@ianlancetaylor
Copy link
Contributor

I have no particular objection to NotifySys. It would need a proposal. I think something like chan syscall.Siginfo might be better than chan any. We should also think about whether anybody might ever want the ucontext argument.

@dothebart
Copy link

In the 90'ies we had this joke:

If a light bulb in Redmond breaks, Microsoft will make darkness the default.

Please fix this and don't make me repeat 30 years old jokes with references to the present times.

@mitar
Copy link
Contributor

mitar commented Jul 20, 2023

Maybe this could be implemented on Linux using signalfd. It seems semantic-wise very similar to how Go maps signals to channels so it might be easier to implement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FeatureRequest help wanted
Projects
None yet
Development

No branches or pull requests

8 participants