[Python-Dev] thread issues when embedding Python

Nick Coghlan ncoghlan at gmail.com
Thu Dec 19 12:22:20 CET 2013

On 19 December 2013 07:58, Daniel Pocock <daniel at pocock.com.au> wrote:
> On 18/12/13 16:29, Victor Stinner wrote:
>> 2013/12/18 Antoine Pitrou <solipsis at pitrou.net>:
>>> You only need to call PyEval_InitThreads() once in the main Python
>>> thread.
>> This is not well documented. For your information, PyGILState_Ensure()
>> now calls PyEval_InitThreads() in Python 3.4, see:
>> http://bugs.python.org/issue19576
> I did see that - but from my own experience, I do not believe it is
> calling PyThreadState_New(..) and it is not even checking if
> PyThreadState_New(..) has ever been called for the active thread
> Consequently, the thread is blocked or there is a seg fault
> I've now written up a much more thorough overview of my experience on my
> blog:
> http://danielpocock.com/embedding-python-multi-threaded-cpp

You absolutely should *NOT* have to call PyThreadState_New before
calling PyGILState_Ensure, as it is designed to call it for you (see
http://hg.python.org/cpython/file/2.7/Python/pystate.c#l598). If
calling PyThreadState_New works, but calling PyGILState_Ensure does
not, then something else is broken (such as not initialising the
thread local storage for the GIL state APIs).

I don't see anything in your article about how you ensure that the
main thread of the application *before anything else related to the
embedded Python happens* calls both Py_Initialize() and
PyEval_InitThreads(). If you don't do that, then all bets are off in
terms of multithreading support.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list