Thread safety of the python API

[Stephen Ludin]

I am developing an application that I may want to make scriptable with
python.  If I do so I'd like to use the convenience of the Python API
in the rest of my application for containers and user defined method
dispatch.  I am concerned though about using the API in a
multit-hreaded program.  For example, a browse of intobject.c shows:

static PyIntObject *free_list = NULL;
...
PyObject *
PyInt_FromLong(long ival)
{
...
	if (free_list == NULL) {
		if ((free_list = fill_free_list()) == NULL)
			return NULL;
	}
	/* PyObject_New is inlined */
	v = free_list;
	free_list = (PyIntObject *)v->ob_type;
...
}

The use of the linked list 'free_list' could result in a race
condition in MT code.  There are a number of similar cases in the
objects defined in the Objects directory.

I have not found much information on this, so I am wondering if I am
missing something.  If all of my use was limited to embedded
interpreters, the global interpreter lock would take care of
synchronization, but I want to use it in the rest of my program as
well.

Is it a bad idea to use the Python API in multi-threaded code?  Is
there an easy way around the seemingly unsafe code?

I am using the 2.0 version of python running on a RedHat 6.2 box with
gcc 2.91.

Thanks,

Stephen