On 19 December 2013 07:58, Daniel Pocock <dan...@pocock.com.au> wrote: > > > On 18/12/13 16:29, Victor Stinner wrote: >> 2013/12/18 Antoine Pitrou <solip...@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. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
