On Fri, 21 Apr 2000, Brent Fulgham wrote:
... The problem is that having to grab the global interpreter lock every time I want to manipulate Python objects from C seems wasteful. This is perhaps more of a "interpreter" issue, rather than a thread issue perhaps, but it does seem that if each thread (and therefore interpreter state from my perspective) kept internal track of itself, there would be much less lock contention as one interpreter drops out of Python into the C code for a moment, then releases the lock and returns, etc.
So I think it's possible that free-threading changes might provide some benefit even on uniprocessor systems.
This is true. Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS become null macros. Your C extensions operate within their thread of execution, but have no central lock to worry about releasing before they block on something.
And from an embedding standpoint, the same is true. You do not need to acquire any locks to start manipulating Python objects. Each object maintains its own integrity.
Note: embedding/extending *can* destroy integrity. For example, tuples have no integrity locking -- Python programs cannot change them, so you cannot have two Python threads breaking things. C code can certainly destroy things with something this simple:
Py_DECREF(PyTuple_GET_ITEM(tuple, 3)); PyTuple_SET_ITEM(tuple, 3, ob);
Exercise for the reader on why the above code is a disaster waiting to happen :-)