[Solved] Why GIL is not synchrionizing Python threads that are running native C++ code inside a DLL?


From [Python 3]: ctypes – Loading shared libraries (emphasis is mine; thanks @user2357112 for pointing out this very explicit quote (waay better than what I’ve originally posted)):

The Python global interpreter lock is released before calling any function exported by these libraries, and reacquired afterwards.

You can also find this statement in other forms on the same page (check PyDLL, CFUNCTYPE).

There are ways of going around the GIL limitation:

  • Replacing the threading module usage by multiprocessing ([Python 3]: multiprocessing – Process-based parallelism). This is the most common one

  • Enclosing code blocks that can be executed in parallel in Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS. The drawback would be that the .dll(s) will now depend on Python

9

solved Why GIL is not synchrionizing Python threads that are running native C++ code inside a DLL?