Document differences between std::process::abort and std::intrinsics::abort

[SimonSapin]

#37833 mentions clean ups done by the former that, as far as I know, the latter doesn’t do.

[alexcrichton]

Neither of these perform any cleanups (it's exit that cleans up, not abort). The process version is the platform-specific approach wheras the intrinsics version is the processor-specific approach, typically an illegal instruction.

[SimonSapin]

Perhaps clean-up is not the right word, I was referring to this PR message:

This calls libc abort on Unix and fastfail on Windows, first running cleanups to do things like flush stdout buffers. This matches with libc abort's behavior, which flushes open files.

The std::process::abort docs already say that Rust destructors are not run.

[alexcrichton]

I believe that's another "forgot to update the PR description with precisely what was merged problem". We don't run cleanups on abort.

[SimonSapin]

Alright, so this is another detail that would be good to clarify in docs.

[Mark-Simulacrum]

It's not quite clear to me what we should clarify in docs here. The only thing that I can potentially see is a note on std::intrinsics::abort that it will not run cleanups -- but I'm not sure we should really document intrinsics.

[SimonSapin]

I don’t know what the differences are or what "cleanups" includes exactly. servo/servo#16899 is a case where process::abort and intrinsics::abort are significantly different.

Calling process::abort from the crash handler causes the crash handler to be invoked again recursively.

[nagisa]

The intrinsics::abort says that its stabilised version is process::abort which is obviouosly not true, because process::abort does not call intrinsics::abort. For those who need a lightweight trap process::abort is not suitable.

[DevQps]

Neither of these perform any cleanups (it's exit that cleans up, not abort). The process version is the platform-specific approach wheras the intrinsics version is the processor-specific approach, typically an illegal instruction.

@alexcrichton So if I understand correctly what needs to be done is documenting these two points right?:

• Document that std::intrinsics::abort uses a processor-specific approach.
• Document that std::process::abort uses a platform-specific approach.

Or do you believe that this distinction should not be documented in the docs? Otherwise we should probably close this issue.

[alexcrichton]

I didn't open this issue, so I'll leave that to @SimonSapin, although this is a very old issue so it's likely out of cache for everyone involved.

[SimonSapin]

As far as I can tell, on Linux x64 intrinsics::abort() cause a CPU exception which makes the kernel terminate the process, and process::abort() calls libc::abort which is documented to trigger the SIGABRT signal which (after possibly running a signal handler) also eventually terminates the process.

I don’t know how to document this in a OS- and architecture-independent way, or more importantly why should one be picked over the other.

[DevQps]

@SimonSapin I just read through the docs of process::abort again and it seems that they already make some statements about cleanup:

From std::process::abort

The function will never return and will immediately terminate the current process in a platform-specific "abnormal" manner.

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.

I guess it might better to no document the platform specifics and rather leave it as it is? That way the process::abort function could potentially be implemented differently in the future without people relying on the specific behavior of a certain platform.

If you agree we can close this issue!