-
Notifications
You must be signed in to change notification settings - Fork 689
Support custom signals for sigaction #2319
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
Comments
This option isn't that bad, and I think this is something we should do, without this, Nix cannot be used under scenarios where interaction with raw libc types is necessary. Actually, this has been done to a lot of Nix wrapper types, though the way they did this are not consistent, some types directly expose it, some types have functions like cc @asomers, do you think we should make the way how our wrapper type interact with the libc types unified? In my mind, I think we should:
|
Yes, definitely @SteveLauC . That's a good idea. |
Thank you very much for your answers! |
sigaction
currently only accepts theSignal
enum and directly passes it tolibc::sigaction
as a c_int.I'm working on a linux system that has custom signals superior to 32. And thus not declared in the Signal enum.
The idea would be to have another
sigaction
function that accepts directly ac_int
.Something like
It might be a bit out of scope for this library ... let me know!
I looked into implementing the function myself, but since Sigaction's fields are not public, I cannot have this function inside my own library. So another way would be to make
sigaction
public, but I feel like it's not ideal.The text was updated successfully, but these errors were encountered: