-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Add current_pid function #45059
Add current_pid function #45059
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @BurntSushi (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
src/libstd/process.rs
Outdated
/// Basic usage: | ||
/// | ||
/// ```no_run | ||
/// use std::process:current_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.
Missing a colon in process::current_pid
.
@@ -209,3 +209,7 @@ pub fn exit(code: i32) -> ! { | |||
let _ = syscall::exit(code as usize); | |||
unreachable!(); | |||
} | |||
|
|||
pub fn getpid() -> u32 { | |||
syscall::getpid().unwrap() as 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.
pid_t
is a usize
on redox, so this may lose 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.
Does Redox really allow PIDs greater than 4 billion-ish though?
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.
If it does, we'll need to reconsider the current Child::id
method.
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 made it a u32 to be consistent with Child::id
.
@@ -513,3 +513,7 @@ pub fn home_dir() -> Option<PathBuf> { | |||
pub fn exit(code: i32) -> ! { | |||
unsafe { libc::exit(code as c_int) } | |||
} | |||
|
|||
pub fn getpid() -> u32 { | |||
unsafe { libc::getpid() as 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.
pid_t
is technically signed by standard, defined as i32
on all of libc
's unix platforms.
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, but getpid()
is guaranteed to return a non-negative number, and so u32
is valid here. The signed-ness represents process groups, not IDs.
src/libstd/process.rs
Outdated
/// | ||
/// | ||
#[unstable(feature = "getpid", issue = "44971", reason = "recently added")] | ||
pub fn current_pid() -> 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 think i64
or u64
would be more prudent.
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 use u32 elsewhere: https://doc.rust-lang.org/std/process/struct.Child.html#method.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.
Yep, that's why I chose u32. Although I think usize or u64 would probably make more sense for both.
I think I might lean towards |
@rfcbot fcp merge |
Team member @sfackler has proposed to merge this. The next step is review by the rest of the tagged teams: No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
Looks good to me! I might throw out the names |
ping @BurntSushi and @aturon for your ticky boxes here! |
Ping @BurntSushi, @aturon again — ticky boxes~ |
Checking off for @BurntSushi as well -- because this is an unstable function, full FCP isn't really needed. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
@bors: r+ |
📌 Commit 29b319b has been approved by |
Add current_pid function Fixes rust-lang#44971
☔ The latest upstream changes (presumably #45532) made this pull request unmergeable. Please resolve the merge conflicts. |
Fixes #44971