Document the runtime environment assumptions of `std`

[joboet]

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: std is not used when the C platform functions are not available. E.g. using clone on Linux and then calling into std is definitely not sound. (This one is very obvious)
• std is not called from an asynchronous signal handler or after fork. std makes no attempt at being async-signal-safe (except for panic! after always_abort has been called).
• On UNIX: threads must not be exited or cancelled (e.g. using pthread_exit or pthread_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 with pin! 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: sigaltstack is not used by code that does not also install it's own handlers for SIGSEGV and SIGBUS (only applicable when sigaltstack is used in threads not spawned by std).
  std uses 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. std makes sure to always access the relevant variables before setting up a sigaltstack, 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 that std'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_atexit is recursively called. It has since been fixed, but our minimum supported version is not high enough to include the fix.
• ...

[ifsheldon]

This could be extended to wasi targets, in which the assumptions of std can easily invalidated. See #133235

[ChrisDenton]

I would emphasise that this is going to be highly target specific. Most of these don't apply to pc-windows-msvc, except maybe the first but I'd phrase that as the pc-windows-msvc targets attempt to target desktop/server applications (albeit we are willing to make reasonable accommodations for other uses) so, for example, kernel32.dll is assumed to exist and be usable. We could have std windows-msvc targets that do target the kernel or UWP or whatever else but those would be separate targets.

[RalfJung]

While TLS accesses are not documented to be async-signal-safe, they mostly are – except for the first access to a variable

This seems to also be an assumption. Is it worth trying to get runtimes and POSIX or even C to document this?

[joboet]

I've got no clue whom to approach for that or if this is even realistic, but sure it'd be great!

[RalfJung]

Let's open a separate issue to discuss and track that: #133698

[hkBst]

• E.g. using clone on Linux and then calling into std is definitely not sound. (This one is very obvious)

Is this talking about the clone syscall (instead of Clone::clone)? Which would allow violating the rules of references?