-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows: Load synch functions together #100710
Conversation
Attempt to load all the required sync functions and fail if any one of them fails. This reintroduces a macro for optional loading of functions but keeps it separate from the fallback macro rather than having that do two different jobs.
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
/// | ||
/// The module must not be unloaded. | ||
pub unsafe fn load_system_library(name: &CStr) -> Option<Self> { | ||
let module = c::LoadLibraryExA( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So previously we loaded this via GetModuleHandle no? Is there a reason to change? IIUC this one is UB (well, deadlock in practice) to call with the loader lock held, which is slightly unfortunate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(That said if theres a reason to use this instead, that's probably fine)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was looking into #78444 and yeah, it should properly be LoadLibrary
because the only two dlls that are guaranteed loaded are ntdll and kernel32. But then again "api-ms-win-core-synch-l1-2-0" is a kind of a virtual dll that may resolve to kernel32 anyway (or might not).
My thought was it shouldn't be too much of an issue in practice considering that using synchronization while the loader lock is held is already very sketchy and that in practice the required module will (hopefully) already be loaded.
That said, I'd be ok with reverting this part if it's too controversial.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, fair enough, I think we can keep it as is and see if anybody ends up complaining. This should only be triggered (I think) if people actually need to block, anyway.
LGTM @bors r+ |
📌 Commit eb54b93fd4c937f1326237feb28edaff8cedcef9 has been approved by It is now in the queue for this repository. |
@bors r- fixing a mistake |
eb54b93
to
625e7e9
Compare
@bors r=thomcc |
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#99415 (Initial implementation of REUSE) - rust-lang#99544 (Expose `Utf8Lossy` as `Utf8Chunks`) - rust-lang#100585 (Fix trailing space showing up in example) - rust-lang#100596 (Remove unnecessary stderr files) - rust-lang#100642 (Update fortanix-sgx-abi and export some useful SGX usercall traits) - rust-lang#100691 (Make `same_type_modulo_infer` a proper `TypeRelation`) - rust-lang#100693 (Add LLVM15-specific codegen test for `try`/`?`s that now optimize away) - rust-lang#100710 (Windows: Load synch functions together) - rust-lang#100807 (Add TaKO8Ki to translation-related mention groups) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Attempt to load all the required sync functions and fail if any one of them fails.
This fixes a FIXME by going back to optional loading of
WakeByAddressSingle
.Also reintroduces a macro for optional loading of functions but keeps it separate from the fallback macro rather than having that do two different jobs.
r? @thomcc