Document the runtime environment assumptions of `std`
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.1k
- PR merge metrics
- PR metrics pending
Description
std makes a number of assumptions about the runtime environment that go beyond what is guaranteed by the ABI. They should be documented somewhere. I'm filing this issue to both collect these assumptions and have a discussion about what the best place is to put them.
Assumptions std makes:
- On pretty much any platform:
stdis not used when the C platform functions are not available. E.g. usingcloneon Linux and then calling intostdis definitely not sound. (This one is very obvious) stdis not called from an asynchronous signal handler or afterfork.stdmakes no attempt at being async-signal-safe (except forpanic!afteralways_aborthas been called).- On UNIX: threads must not be exited or cancelled (e.g. using
pthread_exitorpthread_cancel).
This is because cancellation does not result in proper unwinding meaning destructors aren't called, but the thread's stack is reused – this is incompatible withpin!and probably a bunch of library code. - On UNIX: the stdio file descriptors (
STDIN_FILENO,STDOUT_FILENO,STDERR_FILENO) are assumed to be usable as standard input/output/error.
* On UNIX:sigaltstackis not used by code that does not also install it's own handlers forSIGSEGVandSIGBUS(only applicable whensigaltstackis used in threads not spawned bystd).
stduses TLS variables to store the address of the stack guard page. While TLS accesses are not documented to be async-signal-safe, they mostly are – except for the first access to a variable.stdmakes sure to always access the relevant variables before setting up asigaltstack, thereby ensuring that the TLS accesses are safe when the signal handler is successfully called. User code has no access to these variables and therefore cannot initialize them, so it must ensure thatstd's signal handler is not called when they could be uninitialized. - On older macOS systems: the first access to any TLS variable with a destructor is not done from within
_tlv_atexit.
There was a platform bug that resulted in crashes when_tlv_atexitis recursively called. It has since been fixed, but our minimum supported version is not high enough to include the fix. - ...
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue lists runtime assumptions for std across general platforms, UNIX, and older macOS, but names no target file, test, or entry point. Start by locating where std's platform and runtime assumptions are documented, then compare that coverage with the listed assumptions. Done means the assumptions are collected in an agreed location with their platform scope and safety constraints clear.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- documentation, operating-systems
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100