[C++-sig] Am I crazy or is it my computer?

Matthew Scouten matthew.scouten at gmail.com
Tue Oct 30 16:58:05 CET 2007


This is diving me nuts. I need to triple check an assumption.

I am *extending* python using Boost::Python, by wrapping a complex c++
library that was written years ago with no thought of future use in
python.

The library works by a system of callouts and callbacks with extensive
multithreading.

There are a number of minor worker threads in the background, but
[ASSUMPTION ONE:] this should not matter because they never need to
use data or call code that is known to the interpretor.

There is also a callback thread on which the callbacks are called.
This is NOT a python thread, an interpretor thread, or ANY other
special kind of thread. It was not started through the C/Python API.
It is a system thread started through the WIN32 API in the byzantine
depths of the library. It has not been introduced to the interpretor
in any way.

ASSUMPTION TWO:
I can have that thread call into python code by using the
PyGILState_Ensure & PyGILState_Release pair of functions as described
in http://www.python.org/dev/peps/pep-0311/ and
http://docs.python.org/api/threads.html to acquire the Global
Interpretor Lock.

(Actually:  I am using Resource Acquisition Is Initialization idiom
with the following simple class:

class callback
{
public:
	inline callback()
	{
		state = PyGILState_Ensure();
	}

	inline ~callback()
	{
		PyGILState_Release(state);
	}

private:
	PyGILState_STATE state;
};

This may be ASSUMPTION THREE)

Are my assumptions valid?

This may seem like a simple question that I should be googling for,
but like I said I am triple checking some assumptions. I have been
trying to debug the same extremely bizarre  problem for a couple of
days now and it only shows up in the asynchronous callbacks.



More information about the Cplusplus-sig mailing list