Skip to content
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

Remove windows-sys dependency #374

Merged
merged 4 commits into from
Mar 21, 2023
Merged

Remove windows-sys dependency #374

merged 4 commits into from
Mar 21, 2023

Conversation

Jake-Shadle
Copy link
Contributor

@Jake-Shadle Jake-Shadle commented Mar 20, 2023

This replaces the windows-sys dependency with manual bindings to only the functions, types, and constants needed by parking_lot.

Rationale

parking_lot is a foundational dependency, and thus its choice of dependencies has a fairly wide effect on the ecosystem since it's almost inevitable that even a moderately sized dependency graph will pull it in. This is particularly true due the problematic issue I pointed out in microsoft/windows-rs#1720, in which I actually used parking_lot as an example due to its foundational nature. Using bindings in the few places they are needed means we can completely get rid of the windows-sys dependency, positively impacting a huge part of the crates ecosystem with no negatives.

  1. Win32 functions/types/constants will never change, there is no reason to use an external crate of bindings
  2. parking_lot_core already has manual bindings to Nt* functions since they are not officially supported by Microsoft and thus not part of the Win32 metadata used to generate the windows-sys bindings.

See #332 for a related open issue, and #334 (comment)

Comment on lines -63 to 65
Box::from_raw(backend_ptr);
let _ = Box::from_raw(backend_ptr);
&*global_backend_ptr
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clippy fix

Comment on lines -166 to 167
// Note that this is manually defined here rather than using the definition
// through `winapi`. The `winapi` definition comes from the `synchapi`
// header which enables the "synchronization.lib" library. It turns out,
// however that `Sleep` comes from `kernel32.dll` so this activation isn't
// necessary.
//
// This was originally identified in rust-lang/rust where on MinGW the
// libsynchronization.a library pulls in a dependency on a newer DLL not
// present in older versions of Windows. (see rust-lang/rust#49438)
//
// This is a bit of a hack for now and ideally we'd fix MinGW's own import
// libraries, but that'll probably take a lot longer than patching this here
// and avoiding the `synchapi` feature entirely.
extern "system" {
fn Sleep(a: u32);
}
unsafe {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment was referring to the previous winapi crate usage, and was misleading and irrelevant.

Comment on lines -23 to 19
WaitOnAddress: extern "system" fn(
Address: *mut ffi::c_void,
CompareAddress: *mut ffi::c_void,
AddressSize: usize,
dwMilliseconds: u32,
) -> BOOL,
WakeByAddressSingle: extern "system" fn(Address: *mut ffi::c_void),
WaitOnAddress: WaitOnAddress,
WakeByAddressSingle: WakeByAddressSingle,
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These functions were incorrectly not marked unsafe.

Comment on lines -35 to 24
// MSDN claims that that WaitOnAddress and WakeByAddressSingle are
// located in kernel32.dll, but they are lying...
let synch_dll = unsafe { GetModuleHandleA(b"api-ms-win-core-synch-l1-2-0.dll\0".as_ptr()) };
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment is outdated, MSDN does show this as the library that implements those functions.

@Amanieu Amanieu merged commit 92b4150 into Amanieu:master Mar 21, 2023
@Jake-Shadle Jake-Shadle deleted the remove-windows-sys branch March 21, 2023 16:46
@kennykerr
Copy link
Contributor

kennykerr commented Apr 3, 2023

Reminder to adopt standalone code generation support as this PR alone leaves you vulnerable to linker issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants