[Git][ghc/ghc][wip/rts-mutex-static-initializer] rts: replace initMutex/closeMutex with static initializer
Cheng Shao pushed to branch wip/rts-mutex-static-initializer at Glasgow Haskell Compiler / GHC
Commits:
c2d9398a by Cheng Shao at 2025-12-12T01:41:00+01:00
rts: replace initMutex/closeMutex with static initializer
This patch drops all `initMutex`/`closeMutex` logic from the RTS, and
instead define and use a static initializer `MUTEX_INIT` to initialize
a `Mutex`. For both pthreads/win32 cases, a mutex is just a
process-private cheap resource that doesn't really need to be freed
upon RTS exit; it can be statically initialized inplace using either
`PTHREAD_MUTEX_INITIALIZER` or `SRWLOCK_INIT`, hence we define
`MUTEX_INIT` and prefer to use it to initialize a `Mutex`.
All `closeMutex` invocations are dropped. Most `initMutex` invocations
are dropped, except non-global ones, and the ones that need to be
re-initialized in the child process after `forkProcess`, these are
replaced by assigning `MUTEX_INIT`. The patch also drops
`initIpe`/`exitIpe`/`stat_exit` since they are now no-ops. Also cleans
up legacy wasm32 stub definitions, since wasi-libc started shipping
basic pthread stubs in wasip1 sysroot.
Sadly, we can't do the same for condition variables, since
`PTHREAD_COND_INITIALIZER` defaults to real-time but we want monotonic
time.
The main motivation of this patch is not just housecleaning: it is to
make it easier to acquire/release a global Mutex in C initializer
functions generated by GHC (some custom instrumentation for debugging
purpose). Now that a global Mutex can be statically initialized
in-place using `MUTEX_INIT`, the initializer code can acquire/release
it without worrying about Mutex initialization, otherwise it needs to
be initialized in another initializer function with higher priority,
which complicates the implementation.
Co-authored-by: Codex
participants (1)
-
Cheng Shao (@TerrorJack)