Rust: Tracking issue for std::process::id

[tmccombs]

The standard library provides a way to get the process id of a child process with std::process::Child::id(), but doesn't have any way to get the current processes id (the equivalent of getpid).

It is possible to do this with libc::getpid, 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.

[sfackler]

Seems reasonable to add!

[retep998]

GetCurrentProcessId on Windows.

[sfackler]

Reopening as the tracking issue.

[EdSchouten]

While porting Rust over to CloudABI, 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 fork()/execve() model doesn't lend well to sandboxing. Maybe it makes more sense to disable std::process on CloudABI entirely.

[tmccombs]

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 std::process::Child::id, which is already stabilized. I'm not sure how you would deal with that either.

[sfackler]

As @tmccombs has mentioned, the ship has already sailed here due to Child::id. 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.

[EdSchouten]

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 i32. On CloudABI, it could be a string. That way, existing code that uses i32 continues to build on existing platforms, whereas less conventional platforms can choose to implement this function differently.

[SimonSapin]

Given this:

That said, almost all of the other functions provided by this module are also broken on CloudABI. The traditional fork()/execve() model doesn't lend well to sandboxing. Maybe it makes more sense to disable std::process on CloudABI entirely.

and this:

the ship has already sailed here due to Child::id

I’m inclined to stabilize std::process::id as-is. (Returning u32.)

@rfcbot fcp merge

Hopefully the portability lint can eventually help a CloudABI port to "cleanly" implement this differently, or not at all.

[rfcbot]

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged teams:

• [x] @Kimundi
• [x] @SimonSapin
• [x] @alexcrichton
• [x] @aturon
• [x] @dtolnay
• [x] @sfackler
• [ ] @withoutboats

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 this document for info about what commands tagged team members can give me.

[rfcbot]

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

[rfcbot]

The final comment period is now complete.