diff options
| author | Matthias Krüger <matthias.krueger@famsik.de> | 2022-08-31 07:57:55 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2022-08-31 07:57:55 +0200 |
| commit | b2a8d9d86c02eb0a248cdeed0ca77da589e05572 (patch) | |
| tree | 9f33552ec98e5b3fcc5eac08d02f6599c9c1f152 /compiler/rustc_codegen_llvm/src | |
| parent | ea9c370ffec63dc4a94e758790f31e6b14e8d5b5 (diff) | |
| parent | 7bb47a6f38d2c4673663fa1370817c7fb5e682c1 (diff) | |
| download | rust-b2a8d9d86c02eb0a248cdeed0ca77da589e05572.tar.gz rust-b2a8d9d86c02eb0a248cdeed0ca77da589e05572.zip | |
Rollup merge of #100984 - ChrisDenton:reinstate-init, r=Mark-Simulacrum
Reinstate preloading of some dll imports I've now come around to the conclusion that there is a justification for pre-loading the synchronization functions `WaitOnAddress` and `WakeByAddressSingle`. I've found this to have a particularly impact in testing frameworks that may have short lived processes which immediately spawn lots of threads. Also, because pre-main initializers imply a single-threaded environment, we can switch back to using relaxed atomics which might be a minor perf improvement on some platforms (though I doubt it's particularly notable). r? ``@Mark-Simulacrum`` and sorry for the churn here. For convenience I'll summarise previous issues with preloading and the solutions that are included in this PR (if any): **Issue:** User pre-main initializers may be run before std's **Solution:** The std now uses initializers that are guaranteed to run earlier than the old initializers. A note is also added that users should not copy std's behaviour if they want to ensure they run their initializers after std. **Issue:** Miri does not understand pre-main initializers. **Solution:** For miri only, run the function loading lazily instead. **Issue:** We should ideally use `LoadLibrary` to get "api-ms-win-core-synch-l1-2-0". Only "ntdll" and "kernel32" are guaranteed to always be loaded. **Solution:** None. We can't use `LoadLibrary` pre-main. However, in the past `GetModuleHandle` has always worked in practice so this should hopefully not be a problem. If/when Windows 7 support is dropped, we can finally remove all this for good and just use normal imports.
Diffstat (limited to 'compiler/rustc_codegen_llvm/src')
0 files changed, 0 insertions, 0 deletions
