[issue33895] LoadLibraryExW called with GIL held can cause deadlock

Change by Steve Dower : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue33895] LoadLibraryExW called with GIL held can cause deadlock

Steve Dower added the comment: New changeset 4860f01ac0f07cdc8fc0cc27c33f5a64e5cfec9f by Steve Dower (Tony Roberts) in branch 'master': bpo-33895: Relase GIL while calling functions that acquire Windows loader lock (GH-7789)

[issue33895] LoadLibraryExW called with GIL held can cause deadlock

Steve Dower added the comment: Sorry for the delay on this. I've approved the PR and restarted the CI systems to make sure it's all okay. I agree that many of these cases no longer have to dynamically load the functions, but that should be fixed separately. -- versions: -Python

[issue33895] LoadLibraryExW called with GIL held can cause deadlock

Eryk Sun added the comment: In some of these cases, it would be simpler to just remove the explicit dynamic linking. 3.6+ doesn't support XP, so CancelIoEx, CreateSymbolicLinkW, RegDeleteKeyExW, RegDisableReflectionKey, RegEnableReflectionKey, and RegQueryReflectionKey can be linked

[issue33895] LoadLibraryExW called with GIL held can cause deadlock

Tony Roberts added the comment: Sure, that's reasonable :) For my case I have a usable workaround so not back porting it to < 3.8 is fine for me. My workaround will just leak the thread state if another thread is in __import__, which happens so rarely that it's not really a problem (but not

[issue33895] LoadLibraryExW called with GIL held can cause deadlock

Steve Dower added the comment: Yeah, just after posting I remembered that the blocker is the loader lock and not filesystem/arbitrary code. Still, "I don't think" isn't sufficient to justify making the change in 3.7 or earlier. If we can show that properly working code could never have

[issue33895] LoadLibraryExW called with GIL held can cause deadlock

Tony Roberts added the comment: GetProcAddress and GetModuleHandle do block in the same way as LoadLibrary and FreeLibrary - they acquire the loader lock too. Yes, ideally the application would terminate its threads cleanly, however when Python is embedded in another application it may not

[issue33895] LoadLibraryExW called with GIL held can cause deadlock

Steve Dower added the comment: What about existing code that assumes the GIL is already held? Also, your patch addresses many more situations than raised here, most of which are unnecessary (GetProcAddress and GetModuleHandle don't block in the way that LoadLibrary and FreeLibrary may).

[issue33895] LoadLibraryExW called with GIL held can cause deadlock

Change by Tony Roberts : -- keywords: +patch pull_requests: +7393 stage: needs patch -> patch review ___ Python tracker ___ ___

[issue33895] LoadLibraryExW called with GIL held can cause deadlock

Tony Roberts added the comment: Sure, I'll get that done in the next couple of days. -- ___ Python tracker ___ ___

[issue33895] LoadLibraryExW called with GIL held can cause deadlock

Antoine Pitrou added the comment: Do you want to submit a PR for this? You can take a look at our developer's guide if you're new to contributing to Python: https://devguide.python.org/ -- nosy: +pitrou stage: -> needs patch type: -> behavior versions: -Python 2.7, Python 3.4,

[issue33895] LoadLibraryExW called with GIL held can cause deadlock

New submission from Tony Roberts : In dynload_win.c LoadLibraryExW is called with the GIL held. This can cause a deadlock in an uncommon case where the GIL also needs to be acquired when another thread is being detached. Both LoadLibrary and FreeLibrary acquire the Windows loader-lock. If