pub fn exit(code: i32) -> !Expand description
Terminates the current process with the specified exit code.
This function will never return and will immediately terminate the current process. The exit code is passed through to the underlying OS and will be available for consumption by another process.
Note that because this function never returns, and that it terminates the
process, no destructors on the current stack or any other thread’s stack
will be run. If a clean shutdown is needed it is recommended to only call
this function at a known point where there are no more destructors left
to run; or, preferably, simply return a type implementing Termination
(such as ExitCode or Result) from the main function and avoid this
function altogether:
In its current implementation, this function will execute exit handlers registered with atexit
as well as other platform-specific exit handlers (e.g. fini sections of ELF shared objects).
This means that Rust requires that all exit handlers are safe to execute at any time. In
particular, if an exit handler cleans up some state that might be concurrently accessed by other
threads, it is required that the exit handler performs suitable synchronization with those
threads. (The alternative to this requirement would be to not run exit handlers at all, which is
considered undesirable. Note that returning from main also calls exit, so making exit an
unsafe operation is not an option.)
§Platform-specific behavior
Unix: On Unix-like platforms, it is unlikely that all 32 bits of exit
will be visible to a parent process inspecting the exit code. On most
Unix-like platforms, only the eight least-significant bits are considered.
For example, the exit code for this example will be 0 on Linux, but 256
on Windows:
§Safe interop with C code
On Unix, this function is currently implemented using the exit C function exit. As
of C23, the C standard does not permit multiple threads to call exit concurrently. Rust
mitigates this with a lock, but if C code calls exit, that can still cause undefined behavior.
Note that returning from main is equivalent to calling exit.
Therefore, it is undefined behavior to have two concurrent threads perform the following without synchronization:
- One thread calls Rust’s
exitfunction or returns from Rust’smainfunction - Another thread calls the C function
exitorquick_exit, or returns from C’smainfunction
Note that if a binary contains multiple copies of the Rust runtime (e.g., when combining
multiple cdylib or staticlib), they each have their own separate lock, so from the
perspective of code running in one of the Rust runtimes, the “outside” Rust code is basically C
code, and concurrent exit again causes undefined behavior.
Individual C implementations might provide more guarantees than the standard and permit concurrent
calls to exit; consult the documentation of your C implementation for details.
For some of the on-going discussion to make exit thread-safe in C, see: