Windows: guest _Exit hangs in FlipQueue's destructor because ExitProcess still runs module detach routines #2579

On Windows a guest _Exit or _exit can hang instead of ending the process. Homebrew UI Lab (PPSA99050) calls _Exit(EXIT_FAILURE) from ps5-opengl's retirement fail-stop and then stays alive. gdb on the hung process shows one thread in std::_Sp_counted_ptr_inplace<FlipQueue>::_M_dispose (libSceVideoOut.prx), then std::thread::join, then WaitForMultipleObjects.

Cause

On Windows std::_Exit ends in ExitProcess. That still runs every module's DLL_PROCESS_DETACH and its TLS and FLS callbacks, after the other threads have been terminated. FlipQueue's destructor then joins a thread that is already gone and waits forever. POSIX _exit runs no atexit handlers, stream flushes or module destructors.

Fix

AlxcBTW:fix/windows-immediate-exit (2feef9e7, on main c963432). Full CI, with the change merged into main c72d5ce, passes on Linux, macOS and Windows. I can't open it as a PR while intake is limited, so it's here if a collaborator wants to cherry-pick it.

_Exit (libc) and _exit (libkernel) now end the process through LibcTerminate_nid_no_patch. That calls TerminateProcess on Windows and std::_Exit everywhere else.

Tested

Windows 11, WinLibs GCC 15.2.0 r7.

• guest_immediate_exit now also registers an FLS callback that would end the process with 4. It exits with 4 without the change and with 0 with it. ctest -R "kill|exit|process|shutdown|atexit|libc|kernel": 19/19.
• UI Lab: before the change the process stayed alive after submission retirement failed. With it, the process exits with 1 (EXIT_FAILURE).

AI-assisted: yes (Claude Code).