-
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
Improve Wait Documentation #651
Conversation
src/sys/wait.rs
Outdated
Some(bits) => bits.bits(), | ||
None => 0 | ||
}; | ||
let option_bits = options.into().map_or(0, |bits| bits.bits()); |
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.
bits.bits()
reads weird, can you just shorten it to b.bits()
?
src/sys/wait.rs
Outdated
|
||
let res = unsafe { ffi::waitpid(pid.into().unwrap_or(Pid::from_raw(-1)).into(), &mut status as *mut c_int, option_bits) }; | ||
let res = unsafe { | ||
ffi::waitpid(pid.into().unwrap_or ( |
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.
No space before the last (
src/sys/wait.rs
Outdated
0 => StillAlive, | ||
res => decode(Pid::from_raw(res), status), | ||
}) | ||
} | ||
|
||
/// Equivalent to `waitpid(-1, None)`, which waits on any child process of the current process. |
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.
This is confusing because it's actually equivalent to waitpid(None, None)
.
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.
The None
actually converts to -1
inside the function, so it's better to state exactly what None
means, especially given that the original C function doesn't support algebraic data types like None
.
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.
It's still confusing because the code doesn't match the comment until you read it a little more thoroughly. I'm a fan of the "principle of least surprise": I was surprised to read that comment and then see that the code didn't match that, though I later realized they're equivalent. I think it'd be better here to just remove the waitpid...
part and just have a description of what it does. A more descriptive comment below could explain that it's equivalent, but it's definitely not necessary on the title line.
src/sys/wait.rs
Outdated
Stopped(Pid, Signal), | ||
#[cfg(any(target_os = "linux", target_os = "android"))] | ||
PtraceEvent(Pid, Signal, c_int), | ||
/// Signifies that the process received a `SIGCONT` signal, and thus continued. | ||
Continued(Pid), | ||
StillAlive |
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.
I'd like to get some doc comments on StillAlive
and PtraceEvent
since we're here. Are you stuck on understanding those or did you just forget to add them?
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.
I couldn't find any mention of StillAlive
or PtraceEvents
mentioned inthe documentation for waitpid
, so I'm not sure what they do.
src/sys/wait.rs
Outdated
@@ -42,11 +55,15 @@ const WSTOPPED: WaitPidFlag = WUNTRACED; | |||
|
|||
#[derive(Eq, PartialEq, Clone, Copy, Debug)] |
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.
It'd be good to have a comment for the entire enum.
src/sys/wait.rs
Outdated
@@ -25,13 +27,24 @@ libc_bitflags!( | |||
target_os = "android"))] |
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.
Rather than duplicating this libc_bitflags
, could you condense these into one? Before each item you can put the proper #[cfg
so that it still compiles properly. This way we aren't duplicating declarations and comments.
src/sys/wait.rs
Outdated
@@ -25,13 +27,24 @@ libc_bitflags!( | |||
target_os = "android"))] | |||
libc_bitflags!( |
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.
I'd like to see a doccomment for WaitPidFlag
here since you've already documented (nearly) every item.
src/sys/wait.rs
Outdated
/// - If the value of the PID is `0`, it will wait on any child process that has the same | ||
/// group ID as the current process. | ||
/// - If the value of the PID is `-1`, it will wait on any child process of the current process. | ||
/// - If the value of the PID is `None`, the value of PID is set to `-1`. |
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.
Combine this line with the above. But then, what's the point of making Pid
and Option type rather than leaving it numeric if there are two None
cases? In reality, this should take an enum of these different groups, which are then converted to a numeric pid_t
internally. Like:
pub enum PidGroup {
ChildPid(Pid),
ProcessGroupChild(Pid),
GroupChild,
CurrentProcessChild,
}
Then the user uses one of those to specify the option. What do you think about that?
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.
I think that'd be a much better option, although it would require a version bump due to breaking the existing API. I think the best would be to have the parameter value as Into<PidGroup>
, where PidGroup
could also implement From<i32>
, so that we could continue using i32
values as in C in addition.
Or I suppose have the parameter as Into<i32>
where PidGroup
implements Into<i32>
.
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.
We already have breaking changes in this release, and I'm not afraid to have breaking changes when it results in improved APIs. The 0.9 release that will come out soon will have breaking changes, and I don't see that as a problem as long as they're well documented.
Awesome, great work starting this! We always could use more docs, so thanks for the PR! I've got a few general comments beyond what I left about your code:
|
@asomers Another FreeBSD build that failed, and the merge branch here is also |
I'll make a push within 30 mins with all the changes. What do you think though? Should the |
src/sys/wait.rs
Outdated
Exited(Pid, i8), | ||
/// Signifies that the process was killed by a signal, providing the PID and associated signal. |
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.
Could you also please document the bool member?
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.
Once I figure out what the bool
parameter signifies.
No rush on the changes, whenever you've got time is fine. I'm just at a computer, so you're getting nice quick responses! :-) As to your question, it might take some test code that plays with the API to see what's most ergonomic, but I'm inclined to think taking a |
592bd52
to
5a3522f
Compare
src/sys/wait.rs
Outdated
Continued(Pid), | ||
/// if `WNOHANG` was set, this value is returned when no children have changed state. |
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.
Please capitalize if
here.
src/sys/wait.rs
Outdated
/// Designates whether the supplied `Pid` value is a process ID, process group ID, | ||
/// specifies any child of the current process's group ID, or any child of the current process. | ||
pub enum PidGroup { | ||
ProcessID(u32), |
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.
I imagine this would be a lot cleaner if you used the Pid
type here directly instead of u32
. Any reason you didn't?
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.
It's kind of odd to use something other than u32
, as the purpose of separating the variants is to eliminate the need to express meaning through negative values, as Pid
is basically i32
. A negative value indicates a process group ID, whereas a positive value indicates a process ID. If the process ID and group ID are going to get their own variants, it wouldn't make sense to require them to retain their positive and negative values. If you retained the Pid
value, then there'd be less meaning to having both a PID and PGID variant when they'd always get the same value and that value would be treated the same by functions.
If it retained Pid
/i32
then it wouldn't make a difference if you wrote:
match waitpid(ProcessID(pid), WUNTRACED) { }
Or if you wrote
match waitpid(ProcessGroupID(pid), WUNTRACED) {}
The behavior would be entirely dependent upon whether the value supplied to either variant is positive or negative.
Especially when I would, for example, create a PidGroup
manually in Ion by just supplying my existing u32(Linux/BSD)/usize(Redox)
values that I have stored in the shell to the ProcessGroupID
variant, rather than having to do as I do now and convert the u32
into an i32
, and then set the negative bit to signify to the function that I'm wanting to wait/signal a process group. Being able to just designate the PGID with a positive value is more idiomatic.
match waitpid(ProcessGroupID(pid), WUNTRACED) {
...
}
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.
I'm not certain we're quite on the same page with understanding this issue based on your comment here: I'm trying to develop a solution where you never need to negate the pid
as well. My understanding that when using waitpid()
that you will already have a process ID, the question is what does it mean. That extra meaning is why there's the enum type, so even though ProcessID(pid)
and ProcessGroupId(pid)
have the same process id within them, they mean different things. And internally the values would be mapped as the libc::waitpid
function expected. So the point is that the user shouldn't be doing the negation just as you suggested, the value used for ProcessId
and ProcessGroupId
is the same raw pid value.
What we do need to make sure is that the raw value is "correct". For example, the pid
should be positive and non-zero for both of those types, so that should be checked. We can either embed this into the enum type (which I don't know a good implementation for) or embed it within waitpid()
, which is the path I'd suggest.
Is that more clear? Because I think we agree we're just losing something in translation.
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.
It seems, then, that it'd be better if Pid
was mapped to an unsigned integer rather than a signed integer that can be constructed from a negative value, if we need to guarantee that a negative value cannot be mapped. Otherwise, there'd be a cost in having to always check if the value of ProcessGroupID
is negative, and then setting the negative bit if it's positive, else use the value as is. If it was an unsigned integer, then you'd always know that the PGID variant just needs to be converted into a signed integer and have it's negative bit set before passing it to the function. Process IDs are never negative values to begin with.
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.
pid_t
is the underlying type and that's defined by the platform, we don't change that. And yes, there will be a runtime cost of checking these values, but we'd need to check them even if they're unsigned since 0
doesn't make sense for these enum types either.
src/sys/wait.rs
Outdated
pub fn waitpid<P: Into<Option<Pid>>>(pid: P, options: Option<WaitPidFlag>) -> Result<WaitStatus> { | ||
use self::WaitStatus::*; | ||
#[derive(Debug, Copy, Clone, Eq, PartialEq, Hash)] | ||
/// Designates whether the supplied `Pid` value is a process ID, process group ID, |
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.
Please put the comments above #cfg
attributes.
src/sys/wait.rs
Outdated
WUNTRACED, | ||
#[cfg(any(target_os = "linux", |
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.
Please put cfg
statements on one line if they're under 100 characters.
src/sys/wait.rs
Outdated
AnyChild, | ||
} | ||
|
||
impl From<Pid> for PidGroup { |
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.
The From
s for PidGroup
should be removed in favor on embedded Pid
s directly into the specific enum types.
Looking pretty good, the tests didn't get updated. Please fix those on your next update. |
I believe that I have all concerns addressed now. |
src/sys/wait.rs
Outdated
@@ -267,13 +253,14 @@ impl From<i32> for PidGroup { | |||
} | |||
} | |||
|
|||
impl Into<i32> for PidGroup { | |||
fn into(self) -> i32 { | |||
impl Into<pid_t> for PidGroup { |
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.
This is a public implementation that I don't think we want to support. While the first argument of waitpid
is a pid_t
type, it's actually not a "proper" one. As in it's different than the pid_t
you'd get or pass to many other functions, so it's in essence a different type (it's just overloaded in C because of language limitations). I think instead we want to just hardcode this inside of waitpid
or implement it as a private function (so it can be unit tested) instead.
src/sys/wait.rs
Outdated
PidGroup::ProcessGroupID(pid) => -(pid as i32), | ||
PidGroup::AnyGroupChild => 0, | ||
PidGroup::AnyChild => -1 | ||
PidGroup::ProcessID(pid) if pid < Pid::from_raw(-1) => -pid_t::from(pid), |
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.
Please don't align the =>
in match arms, just have them surrounded by one space on each size.
src/sys/wait.rs
Outdated
@@ -233,32 +233,18 @@ fn decode(pid : Pid, status: i32) -> WaitStatus { | |||
/// specifies any child of the current process's group ID, or any child of the current process. | |||
#[derive(Debug, Copy, Clone, Eq, PartialEq, Hash)] |
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.
Can you alphabetize the derived traits?
src/sys/wait.rs
Outdated
/// | ||
/// # Usage Notes | ||
/// | ||
/// - If the value of PID is greater than `0`, it will wait on the child with that PID. |
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.
Can you update these docs now that the pid argument type has changed?
src/sys/wait.rs
Outdated
pub fn waitpid<P: Into<Option<Pid>>>(pid: P, options: Option<WaitPidFlag>) -> Result<WaitStatus> { | ||
/// Designates whether the supplied `Pid` value is a process ID, process group ID, | ||
/// specifies any child of the current process's group ID, or any child of the current process. | ||
#[derive(Debug, Copy, Clone, Eq, PartialEq, Hash)] |
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.
Can you alphabetize these?
src/sys/wait.rs
Outdated
StillAlive | ||
} | ||
|
||
#[cfg(any(target_os = "linux", | ||
target_os = "android"))] | ||
#[cfg(any(target_os = "linux", target_os = "android"))] |
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.
Please alphabetize the list of oses here and everywhere else cfg
is used within the scope of this PR.
src/sys/wait.rs
Outdated
@@ -1,58 +1,72 @@ | |||
use libc::{self, c_int}; | |||
//! This module contains the `wait()` and `waitpid()` functions, which are used |
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.
I think something got left out here, it's an incomplete sentence.
src/sys/wait.rs
Outdated
} | ||
); | ||
|
||
#[cfg(any(target_os = "linux", | ||
target_os = "android"))] | ||
#[cfg(any(target_os = "android", target_os = "linux"))] | ||
const WSTOPPED: WaitPidFlag = WUNTRACED; |
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.
This should actually be included in the WaitPidFlag
bitflag declaration, yes?
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.
Can it be? The other flags are automatically generated via the libc_bitflags!
macro.
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.
We don't want to be defining WSTOPPED
in nix
, instead it should be defined in the libc
crate and we include it on appropriate platforms. It isn't defined in libc
for android
or linux
however, so we'll need a PR for that.
@mmstick For fixing documentation errors, please test these locally first. Tests take 2 hours to run for us and you're pushing so many commits that we have a huge backlog in CI. I've already canceled a bunch of your old pushes because of it. |
That last commit fixed everything. |
src/sys/wait.rs
Outdated
WEXITED, | ||
/// Report the status of any continued child process specified by pid whose status has not | ||
/// been reported since it continued from a job control stop. | ||
#[cfg(any(target_os = "android", target_os = "linux"))] | ||
WCONTINUED, |
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.
WCONTINUED is available pretty much everywhere. Definitely on freebsd
, openbsd
, bitrig
, dragonfly
, netbsd
and solaris
.
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.
(Does nix
even support solaris
? it's waitid on illumos instead of waitpid
…)
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.
WCONTINUED is not mentioned in the macOS manpage, someone with macOS should check there…
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.
It's defined for Mac within libc
, so it should be fine on both macos
and ios
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.
Nice. Probably should just drop the cfg
here
src/sys/wait.rs
Outdated
/// Leave the child in a waitable state; a later wait call can be used to again retrieve | ||
/// the child status information. | ||
#[cfg(any(target_os = "android", target_os = "linux"))] | ||
WNOWAIT, |
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.
WNOWAIT is available on freebsd
and netbsd
.
src/sys/wait.rs
Outdated
WUNTRACED, | ||
/// Waits for children that have terminated. | ||
#[cfg(any(target_os = "android", target_os = "linux"))] | ||
WEXITED, |
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.
WEXITED is available on freebsd
and netbsd
.
This also touches on changes made in #566. I think I'm going to try to get that PR merged first and then this can be rebased afterwards. |
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.
Would be great to get this in the 0.9 release given how much it improves documentation. It's pretty close, mostly just minor documentation changes at this point.
src/sys/wait.rs
Outdated
/// - If the value of the PID is `PidGroup::AnyChild`, it will wait on any child process of the | ||
/// current process. | ||
/// | ||
/// # Possible Error Values |
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.
This should just be # Errors
(see the Rust special documentation section)
src/sys/wait.rs
Outdated
} | ||
} | ||
|
||
/// Waits for and returns events that are received from the given supplied process or process group |
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.
This should be a short descriptive line, then a blank line, then more description. If you run rust doc --no-deps --open
and look at the generated output, you'll see why. The first line is used on the summary page, and the rest is shown on the detailed page.
Additionally this should link to the man page (see how other functions are documented).
@@ -215,24 +262,84 @@ fn decode(pid : Pid, status: i32) -> WaitStatus { | |||
} | |||
} | |||
|
|||
pub fn waitpid<P: Into<Option<Pid>>>(pid: P, options: Option<WaitPidFlag>) -> Result<WaitStatus> { | |||
/// Designates whether the supplied `Pid` value is a process ID, process group ID, |
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.
Same here with the documentation.
src/sys/wait.rs
Outdated
//! child management than the primitives provided by Rust's standard library, and are critical | ||
//! in the creation of shells and managing jobs on *nix platforms. | ||
//! | ||
//! # Example |
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.
This should be # Examples
in line with the special sections syntax
src/sys/wait.rs
Outdated
@@ -1,58 +1,105 @@ | |||
use libc::{self, c_int}; | |||
//! This module contains the `wait()` and `waitpid()` functions, which are used to wait on and |
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.
Short descriptive first line, then a blank line, then more description. Generate the docs locally with rust doc --no-deps --open
to see what I'm talking about.
src/sys/wait.rs
Outdated
/// | ||
/// # Possible Error Values | ||
/// | ||
/// If this function returns an error, the error value will be one of the following: |
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.
You can just remove this sentence as it's superfluous.
src/sys/wait.rs
Outdated
0 => StillAlive, | ||
res => decode(Pid::from_raw(res), status), | ||
}) | ||
} | ||
|
||
/// Waits on any child of the current process, returning on events that change the status of |
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.
Same thing here about a short descriptive first sentence. Also, it should provide a link to the man page (see how other functions are documented). Also it looks like the possible errors are a subset of waitpid
's, so it'd be good to explicitly document them here.
Looks like this also needs a rebase. I'd love to move forward with this and let #566 catch up later as it's currently stalled on the OP. |
Just performed a |
Performed requested changes to the documentation. |
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.
This also needs a rebase, to be squashed into a smaller number of commits (commits that just fix something that wasn't right in an earlier commit should be merged into the earlier commmits), and then a CHANGELOG entry for the change in the API of waitpid()
.
//! | ||
//! Manual Page: http://pubs.opengroup.org/onlinepubs/007908799/xsh/wait.html | ||
//! | ||
//! # Examples |
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.
Please provide a brief description of what this code does, either in text before the example or using comments within the code.
//! | ||
//! # Examples | ||
//! | ||
//! ```rust |
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.
Add ,no_run
at the end since this code example will fail when run.
//! Ok(_) => (), | ||
//! Err(why) => { | ||
//! println!("waitpid returned an error code: {}", why); | ||
//! break |
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.
Add a semi-colon after break
.
AnyChild, | ||
} | ||
|
||
impl From<i32> for PidGroup { |
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.
This should be removed as it's unused and we shouldn't support this for our users.
@mmstick Any interest in cleaning this up a bit? We're close to merging and we would love to have this documentation in |
@mmstick Just pinging you again on this. Do you have time to wrap this up in the near future? |
Noteworthy secondary changes included as a result of the primary documentation: * Additions to unistd::Pid to support waitpid calling conventions * Change the waitpid function signature (backward compatible) * Application of rustfmt to unistd.rs and sys::wait.rs Continued from work by * Marcin Mielniczuk <marmistrz.dev@gmail.com> * Michael Aaron Murphy <mmstickman@gmail.com> Closes nix-rust#654 and nix-rust#651
Noteworthy secondary changes included as a result of the primary documentation: * Additions to unistd::Pid to support waitpid calling conventions * Change the waitpid function signature (backward compatible) * Application of rustfmt to unistd.rs and sys::wait.rs Continued from work by * Marcin Mielniczuk <marmistrz.dev@gmail.com> * Michael Aaron Murphy <mmstickman@gmail.com> Closes nix-rust#654 and nix-rust#651
Noteworthy secondary changes included as a result of the primary documentation: * Additions to unistd::Pid to support waitpid calling conventions * Change the waitpid function signature (backward compatible) * Application of rustfmt to unistd.rs and sys::wait.rs Continued from work by * Marcin Mielniczuk <marmistrz.dev@gmail.com> * Michael Aaron Murphy <mmstickman@gmail.com> Closes nix-rust#654 and nix-rust#651
Noteworthy secondary changes included as a result of the primary documentation: * Additions to unistd::Pid to support waitpid calling conventions * Change the waitpid function signature (backward compatible) * Application of rustfmt to unistd.rs and sys::wait.rs Continued from work by * Marcin Mielniczuk <marmistrz.dev@gmail.com> * Michael Aaron Murphy <mmstickman@gmail.com> Closes nix-rust#654 and nix-rust#651
As the title states, improves the documentation for the wait module by providing documentation where there is currently no documentation. Also, changed the signature of
waitpid
to do as the PID parameter currently does (Into<Option<T>>
), so that you don't have to always typeSome
every time you want to supply a flag -- but you can still provide aNone
value.Closes #643.