Code change:
The standard library provides a way to get the process id of a child process with , but doesn't have any way to get the current processes id (the equivalent of ). It is possible to do this with , but it seems to me that this should be something that is part of the standard library, especially since it already has cross-platform support for process ids of child processes.
Seems reasonable to add!
on Windows.
Reopening as the tracking issue.
While porting Rust over to , a sandboxed UNIX-like runtime environment, I ran into the issue that there is no way for me to implement this function. As we're aiming to use CloudABI in distributed settings, there is no traditional 16/32-bit process identifier. Instead, processes may be identified by a UUID. This is useful, as integer process identifiers can easily collide when dealing with many instances of a job (due to the birthday paradox). As this function was only introduced recently, would it still be possible to alter it to return an opaque, but displayable data type instead? That said, almost all of the other functions provided by this module are also broken on CloudABI. The traditional model doesn't lend well to sandboxing. Maybe it makes more sense to disable on CloudABI entirely.
I'm opposed a completely opaque data type, because that limits the usefulness. For example, that makes it difficult to use in C (or dbus) that require a PID. However, I think it would be alright if the it was a semi-opaque type with OS-specific API's to get the underlying representation (in std::os::unix, etc). However, that would break consistency with , which is already stabilized. I'm not sure how you would deal with that either.
As has mentioned, the ship has already sailed here due to . More generally, though. I'm not sure it makes sense to avoid supporting getpid of all things because some platform decided not to implement it.
One thing that would be low-hanging fruit would be to at least have some kind of type alias for this. On UNIX/Windows, it could be defined as . On CloudABI, it could be a string. That way, existing code that uses continues to build on existing platforms, whereas less conventional platforms can choose to implement this function differently.
Given this: and this: I’m inclined to stabilize as-is. (Returning .) fcp merge Hopefully the can eventually help a CloudABI port to "cleanly" implement this differently, or not at all.
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), 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 for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.

Related discussion:
text: unsafe { ::sys::abort_internal() }; } <ins> /// Returns the OS-assigned process identifier associated with this process. /// /// # Examples /// /// Basic usage: /// /// ```no_run /// #![feature(getpid)] /// use std::process; /// /// println!("My pid is {}", process::id()); /// ``` /// /// #[unstable(feature = "getpid", issue = "44971", reason = "recently added")] pub fn id() -> u32 { ::sys::os::getpid() } </ins> #[cfg(all(test, not(target_os = "emscripten")))] mod tests { use io::prelude::*;