-
Notifications
You must be signed in to change notification settings - Fork 654
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
clone: Allow specifying termination signal #348
Conversation
DO NOT MERGE: proof of concept for comment Fixes nix-rust#343
@tailhook @fiveop @posborne here's another take on a fix for #343, leaning on This is a proof of concept for comment. I'd probably do some more refactoring here first. Eg, I'm considering proposing a newtype for signal numbers, which would be a separate PR that would come first. |
Looks fine if signal will be a new type (or'ing with If it will not be a new type it's better to have |
Build failures are for my doc example using APIs not present in older versions of Rust.
Agreed. We've got #254 open for changing signal to be an enum in nix following from the convention introduced in #282. That would nicely fix the issue. |
|
||
impl CloneFlagsArg { | ||
fn bits(self) -> c_int { | ||
self.flags.bits() | self.signal.unwrap_or(0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To ensure we do not overwrite the other bits, it may make sense to mask self.signal
before or'ing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. It may not be necessary if we use an enum for signals though.... will toy with it over the next few days.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it does. Because only the low 8 signals are allowed if I understand the manpage correctly.
I like it 👍 Agreed on other changes to go with this. |
Some discussion with @arcnmx in the IRC channel (need to get logs enabled there!):
|
Well, let me add a little bit:
I really believe that just using |
I have read all your comments and thought about it. Here is what I think: For the low level API that perfectly matches the C API's there is libc. I do not think we have to provide 1:1 mappings of arguments to functions. In fact, we already do not do this in various places, and this is why I want this library. Otherwise I could just use libc. So I do not agree with @tailhook. Given this first proposition, the remaining proposals given so far fall in two groups: Two separate arguments or one composite argument. I do not see an advante in using a composite argument. It seems like an artifical construct to match the C API argument count (again). Therefore, I support using two seperate arguments. I would use one argument for the I do not specify what enumeration, because I see two options, and have not made my mind up yet: We could either use the enumeration for signals in general, that we plan to add. This would force us to check that the signal is in the valid range in order to provide a safe interface. Or we could create a separate enumeration just for this parameter. We could add code for automatic conversion between the special and the general signal enumeration. On direction of the conversion would have to implement the range checks. However, a user could use the specialised enumeration, if he knows that the signal will be within range (for example because it is constant) and thus avoid the range check. |
hi I'm one of them
nix has a convention of using strongly-typed arguments for API contracts (and ranges of valid values and so forth) that are otherwise only specified in man pages. I don't think this situation is any different, or that there's any rule saying the prototypes must be identical. It's not about being user-friendly, it's about being clean and type-safe. |
I've come around to the argument that in this case having a separate argument exposed from nix for signal/flags probably makes most sense. The combination of the signal/flags in the kernel interface (and libc by extension) appears to be purely an optimization. In general, I believe that for nix it probably makes sense to expose bindings to the logical *nix interface rather than the "physical" one. In this case performing an OR between flags and a signal feels like we are coupling ourselves too closely to the physical interface exposed by the kernel at the expense of clarity. |
Me too. Closing this, and moving discussion to #343. |
DO NOT MERGE: proof of concept for comment
Fixes #343