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 pro
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
Change by Tony Roberts :
--
keywords: +patch
pull_requests: +7393
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Tony Roberts added the comment:
Sure, I'll get that done in the next couple of days.
--
___
Python tracker
<https://bugs.python.org/issue33895>
___
___
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
