Stabilise unix_process_wait_more, extra ExitStatusExt methods

[ijackson]

This stabilises the feature unix_process_wait_more. Tracking issue #80695, FCP needed.

This was implemented in #79982 and merged in January.

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

re-assigning to @yaahc to kick off T-libs-api FCP

[yaahc]

@rfcbot merge

[rfcbot]

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

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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]

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

[BurntSushi]

This LGTM.

Looking at the docs, I note that "system call" is mentioned several times. Is this correct? It would make sense to me if, say, this trait existed for a specific target. But it exists for all of Unix. Are these routines truly implemented as system calls in every Unix operating system? And if so, is that a happy accident, or is it necessarily the case that these things are syscalls? My understanding is that whether something is a syscall or not is really an implementation detail.

(This is very likely a pedantic nit and I don't have much confidence as to whether I'm right or wrong, to be honest.)

[ijackson]

Are these routines truly implemented as system calls in every Unix operating system?

You are technically correct. For example exit is almost never actually a system call: it's a library routine which does Some Stuff and calls _exit. But Unix is more a common cultural understanding, than it is a specification. What is a "system call" is not really a cross-platform-standardised concept. SuS doesn't distinguish system calls and library calls at all.

Indeed Rust might gain platforms which are Unix-like-enough to properly be #[cfg(unix)] but which don't have syscalls as such at all. (Some unikernel environments come to mind. Mind you - the one example we have of a platform where this was tried was Fuchsia where calling it Unix was clearly a mistake and now we have serious square peg / round hole problems.)

But, I think talking about this in terms of system calls makes the documentation clearer, even though it is technically not 100% precise. It emphasises that we are talking about the things which are typically or traditionally the things that cross the kernel/userspace boundary. That is something which is indeed cross-platform to any Unix. Talking about syscalls is better for the docs than speaking in standardese (eg by using terminology from SuS).

Anyone who understands these subtleties will be able to easily see what the documentation means. Someone who does not understand these subtleties is assisted rather than hindered by the use of "system call".

Arguably we should change the reference to exit to _exit, which removes a small imprecision. If people wish, I'd be happy to do that - but I don't think it need block stabilisation.

[BurntSushi]

@ijackson Thanks, that makes sense! I don't have a strong opinion either way, and I'm happy to defer to the judgment of others here. One thing that might help is to leave a link or something to your comment here near the trait definition (not in public API docs) so if someone has the same misunderstanding as me, they'll be able to see that the current verbiage is indeed intentional.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[yaahc]

@bors r+

[bors]

📌 Commit 2ed5665 has been approved by yaahc