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
Tony Roberts added the comment:
Sure, I'll get that done in the next couple of days.
--
___
Python tracker
<https://bugs.python.org/issue33895>
___
___
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:
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
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
