Stabilise unix_process_wait_more, extra ExitStatusExt methods by ijackson · Pull...
source link: https://github.com/rust-lang/rust/pull/88300
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Conversation
(rust-highfive has picked a reviewer for you, use r? to override)
re-assigning to @yaahc to kick off T-libs-api FCP
@rfcbot merge
Team member @yaahc has proposed to merge this. The next step is review by the rest of the tagged team members:
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.
changed the title Stabilise unix_process_await_more, extra ExitStatusExt methods
Stabilise unix_process_wait_more, extra ExitStatusExt methods
Copy link
rfcbot commented 15 days ago
This is now entering its final comment period, as per the review above.
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.)
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.
@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.
Copy link
rfcbot commented 5 days ago
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK