Ok, I just found this: <a href="http://www.boost.org/libs/python/doc/v2/faq.html#threadsupport">http://www.boost.org/libs/python/doc/v2/faq.html#threadsupport</a><br><br>I seems to be saying that I can not do what I want with out patching Boost::Python (or does this only apply to multiple interpretors? )
<br>Is this still true (please tell me it's been fixed)?<br>if so, where can I get this patch and how do I apply it?<br><br>I asked about multi-threading and boost python in on this list a while ago, and got no answer. I took this a a "go ahead, no problems". If I am being an idiot, could you tell me so? Just flame away at me so I know I've been stupid. A lot of people here actually know what they are doing. I do not have that luxury. I am finding boost python extremely complex and non-intuitive. There is also a lack of good documentation (example code is nice to have, but does not constitute proper documentation all by itself).
<br><br><br><br><br><br>On 10/30/07, Matthew Scouten <<a href="mailto:matthew.scouten@gmail.com">matthew.scouten@gmail.com</a>> wrote:<br>> This is diving me nuts. I need to triple check an assumption.<br>> <br>
> I am *extending* python using Boost::Python, by wrapping a complex c++<br>> library that was written years ago with no thought of future use in<br>> python.<br>> <br>> The library works by a system of callouts and callbacks with extensive
<br>> multithreading.<br>> <br>> There are a number of minor worker threads in the background, but<br>> [ASSUMPTION ONE:] this should not matter because they never need to<br>> use data or call code that is known to the interpretor.
<br>> <br>> There is also a callback thread on which the callbacks are called.<br>> This is NOT a python thread, an interpretor thread, or ANY other<br>> special kind of thread. It was not started through the C/Python API.
<br>> It is a system thread started through the WIN32 API in the byzantine<br>> depths of the library. It has not been introduced to the interpretor<br>> in any way.<br>> <br>> ASSUMPTION TWO:<br>> I can have that thread call into python code by using the
<br>> PyGILState_Ensure & PyGILState_Release pair of functions as described<br>> in <a href="http://www.python.org/dev/peps/pep-0311/">http://www.python.org/dev/peps/pep-0311/</a> and<br>> <a href="http://docs.python.org/api/threads.html">
http://docs.python.org/api/threads.html</a> to acquire the Global<br>> Interpretor Lock.<br>> <br>> (Actually: I am using Resource Acquisition Is Initialization idiom<br>> with the following simple class:<br>
> <br>> class callback<br>> {<br>> public:<br>> inline callback()<br>> {<br>> state = PyGILState_Ensure();<br>> }<br>> <br>> inline ~callback()
<br>> {<br>> PyGILState_Release(state);<br>> }<br>> <br>> private:<br>> PyGILState_STATE state;<br>> };<br>> <br>> This may be ASSUMPTION THREE)<br>> <br>
> Are my assumptions valid?<br>> <br>> This may seem like a simple question that I should be googling for,<br>> but like I said I am triple checking some assumptions. I have been<br>> trying to debug the same extremely bizarre problem for a couple of
<br>> days now and it only shows up in the asynchronous callbacks.<br>> <br>