Account for the different signal handler types. #241
Conversation
|
Thinking more about this, the constructor function I see two solutions: Either add/remove those flags everytime (just in case) change the return value to a Result and signal an error, if the flags are not appropriatly set. Both go against the idea of zero cost abstractions. However, we cannot provide a safe interface without them. The third option is to mark the method unsafe and describe in a comment why. This way the caller knows what he has to do, to ensure safety. |
|
I'm not following the reasoning behind not wanting to force the correct setting of |
|
My problem was (and still is) that it is no longer a zero cost abstraction. But all our error handling code already adds additional costs, so I opted to push a variant that sets or unsets the flag as necessary. |
If someone creates so many SigAction structs, that a few extra instructions per object creation create a performance problem, we could still provide an unsafe variant, that let's the user take care of the flag.
| }; | ||
| s.sa_flags = match handler { | ||
| SigHandler::SigAction(_) => flags | SA_SIGINFO, | ||
| _ => flags - SA_SIGINFO, |
There was a problem hiding this comment.
I think flags & !SA_SIGINFO is nicer when removing a single flag. As it is, I had to go and double check that we actually had a bitflags type here.
There was a problem hiding this comment.
I prefer the minus sign, which represents set difference. And that is exactly what we want to express and achieve here. In addition it is more concise.
I do not think that preventing confusion is a valid argument since the type is stated in the parameter list and (now) by convention we use bitflags for such types.
There was a problem hiding this comment.
That is a very reasonable position!
|
Regarding "zero cost", I think your commit comment captures what that means. It's ok to put in a few extra instructions for the infrequent thing, but the actual calling of the signal handlers will have no cost above what you'd expect in C. This differs from, say, Go which handles signals by passing them to channels, or Python, where the signal handlers are Python functions and so there's some per-signal overhead there. |
|
Unless there are further concerns I would like to merge this, in particular, because I want to use it (and apparently others too). |
|
Sounds good to me! |
|
Merged as 645c48f...645e37d. |
This commit would be an API breaking change:
nix::sys::signals::sigactionget's a different signature.It currently leaves the responsibility of passing the
SA_SIGINFOflag if necessary to the user.This might solve part of #49.