gh-152433: Windows: allow build prim.c for UWP#152477
Conversation
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
prim.c for UWP
|
LGTM considering @zooba's #152433 (comment). cc @colesbury who tracks mimalloc differences from upstream in #113141. |
|
This change looks fine, if we're maintaining the sources separately. If we're trying to track upstream closely, then we'll need them to make the change first. That's @colesbury's call, it seems. |
|
Our copy of |
|
Yeah, if it's not CPython specific, please also open a PR in upstream mimalloc. |
|
Patch submitted to upstream (microsoft/mimalloc#1340). Note is a bit different because I think PR can still be merged here because it doesn't do any harm and in the future it will be overwritten by whatever is upstream. |
| @@ -121,21 +123,33 @@ void _mi_prim_mem_init( mi_os_mem_config_t* config ) | |||
| if (si.dwAllocationGranularity > 0) { config->alloc_granularity = si.dwAllocationGranularity; } | |||
| // get the VirtualAlloc2 function | |||
| HINSTANCE hDll; | |||
| #ifndef MS_WINDOWS_DESKTOP | |||
| hDll = LoadPackagedLibrary(L"kernelbase", 0); | |||
There was a problem hiding this comment.
Not sure it's a major issue, but wouldn't GetModuleHandle be the better option? There's 0% chance we've reached this point without these module being loaded, and as they're not packaged libraries I would expect this to fail without the "it's already loaded" fast-path.
All changes are trivial:
Remove some run-time dynamic linking and replace some
LoadLibrarywithLoadPackagedLibraryfor UWP.