On 19/12/13 12:22, Nick Coghlan wrote:
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.
I definitely do both of those things in the method PyRoutePlugin::init(..) It is in PyRoutePlugin.cxx: http://svn.resiprocate.org/viewsvn/resiprocate/main/repro/plugins/pyroute/Py...