On 19 December 2013 07:58, Daniel Pocock <daniel@pocock.com.au> wrote:
On 18/12/13 16:29, Victor Stinner wrote:
2013/12/18 Antoine Pitrou <solipsis@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:
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. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia