Skip to content
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Commit 8f3adf5

Browse files
committedJan 31, 2025
exit: document interaction with C
1 parent a6434ef commit 8f3adf5

File tree

2 files changed

+25
-1
lines changed

2 files changed

+25
-1
lines changed
 

‎library/std/src/env.rs

+1-1
Original file line numberDiff line numberDiff line change
@@ -333,7 +333,7 @@ impl Error for VarError {
333333
///
334334
/// Discussion of this unsafety on Unix may be found in:
335335
///
336-
/// - [Austin Group Bugzilla](https://austingroupbugs.net/view.php?id=188)
336+
/// - [Austin Group Bugzilla (for POSIX)](https://austingroupbugs.net/view.php?id=188)
337337
/// - [GNU C library Bugzilla](https://sourceware.org/bugzilla/show_bug.cgi?id=15607#c2)
338338
///
339339
/// To pass an environment variable to a child process, you can instead use [`Command::env`].

‎library/std/src/process.rs

+24
Original file line numberDiff line numberDiff line change
@@ -2294,6 +2294,30 @@ impl Child {
22942294
/// considered undesirable. Note that returning from `main` also calls `exit`, so making `exit` an
22952295
/// unsafe operation is not an option.)
22962296
///
2297+
/// ## Safe interop with C code
2298+
///
2299+
/// This function is safe to call as long as `exit` is only ever invoked from Rust. However, the C
2300+
/// standard does not permit multiple threads to call `exit` concurrently. Rust mitigates this with
2301+
/// a lock, but if C code calls `exit`, that can still cause undefined behavior. Note that returning
2302+
/// from `main` is equivalent to calling `exit`.
2303+
/// Therefore, it is undefined behavior to have two concurrent threads perform the following
2304+
/// without synchronization:
2305+
/// - One thread calls Rust's `exit` function or returns from Rust's `main` function
2306+
/// - Another thread calls the C function `exit` or `quick_exit`, or returns from C's `main` function
2307+
///
2308+
/// Note that if a binary contains multiple copies of the Rust runtime (e.g., when combining
2309+
/// multiple `cdylib` or `staticlib`), they each have their own separate lock, so from the
2310+
/// perspective of code running in one of the Rust runtimes, the "outside" Rust code is basically C
2311+
/// code, and concurrent `exit` again causes undefined behavior.
2312+
///
2313+
/// Individual C implementations might provide more guarantees than the standard and permit concurrent
2314+
/// calls to `exit`; consult the documentation of your C implementation for details.
2315+
///
2316+
/// For some of the on-going discussion to make `exit` thread-safe in C, see:
2317+
/// - [Rust issue #126600](https://github.com/rust-lang/rust/issues/126600)
2318+
/// - [Austin Group Bugzilla (for POSIX)](https://austingroupbugs.net/view.php?id=1845)
2319+
/// - [GNU C library Bugzilla](https://sourceware.org/bugzilla/show_bug.cgi?id=31997)
2320+
///
22972321
/// ## Platform-specific behavior
22982322
///
22992323
/// **Unix**: On Unix-like platforms, it is unlikely that all 32 bits of `exit`

0 commit comments

Comments
 (0)
Failed to load comments.