Skip to content
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

Merged
merged 3 commits into from
Oct 26, 2017
Merged

Add current_pid function #45059

merged 3 commits into from
Oct 26, 2017

Conversation

tmccombs
Copy link
Contributor

@tmccombs tmccombs commented Oct 6, 2017

Fixes #44971

@rust-highfive
Copy link
Collaborator

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.

/// Basic usage:
///
/// ```no_run
/// use std::process:current_pid;
Copy link
Member

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
Copy link
Member

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.

Copy link
Contributor

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?

Copy link
Member

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.

Copy link
Contributor Author

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 }
Copy link
Member

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.

Copy link
Contributor

@clarfonthey clarfonthey Oct 7, 2017

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.

///
///
#[unstable(feature = "getpid", issue = "44971", reason = "recently added")]
pub fn current_pid() -> u32 {
Copy link
Member

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

@tmccombs tmccombs Oct 7, 2017

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.

@shepmaster shepmaster added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Oct 6, 2017
@sfackler
Copy link
Member

sfackler commented Oct 7, 2017

I think I might lean towards current_id rather than current_pid since we're already in the process module?

@sfackler sfackler added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Oct 7, 2017
@sfackler
Copy link
Member

sfackler commented Oct 7, 2017

@rfcbot fcp merge

@rfcbot
Copy link

rfcbot commented Oct 7, 2017

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.

@rfcbot rfcbot added the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Oct 7, 2017
@alexcrichton
Copy link
Member

Looks good to me! I might throw out the names id or current_id, however to jive better with Child::id (we haven't used "pid" yet)

@shepmaster shepmaster added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 15, 2017
@carols10cents
Copy link
Member

ping @BurntSushi and @aturon for your ticky boxes here!

@kennytm
Copy link
Member

kennytm commented Oct 25, 2017

Ping @BurntSushi, @aturon again — ticky boxes~

@aturon
Copy link
Member

aturon commented Oct 25, 2017

Checking off for @BurntSushi as well -- because this is an unstable function, full FCP isn't really needed.

@rfcbot rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Oct 25, 2017
@rfcbot
Copy link

rfcbot commented Oct 25, 2017

🔔 This is now entering its final comment period, as per the review above. 🔔

@kennytm kennytm added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Oct 25, 2017
@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Contributor

bors commented Oct 25, 2017

📌 Commit 29b319b has been approved by alexcrichton

@kennytm kennytm added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 25, 2017
kennytm added a commit to kennytm/rust that referenced this pull request Oct 25, 2017
bors added a commit that referenced this pull request Oct 25, 2017
Rollup of 7 pull requests

- Successful merges: #45059, #45212, #45398, #45483, #45496, #45508, #45526
- Failed merges:
@bors
Copy link
Contributor

bors commented Oct 26, 2017

☔ The latest upstream changes (presumably #45532) made this pull request unmergeable. Please resolve the merge conflicts.

@bors
Copy link
Contributor

bors commented Oct 26, 2017

⌛ Testing commit 29b319b with merge e847f30...

@bors bors merged commit 29b319b into rust-lang:master Oct 26, 2017
@tmccombs tmccombs deleted the pid branch April 3, 2018 01:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.