[Python-Dev] Making python C-API thread safe (try 2)

[Brian Quinlan]

> The point I was trying to make (not in this message but in general) is
> that it would be simple (trivial but tedious) to create a version of
> Python that is thread-safe, and the only reason it is not done is
> because it would break old code. 

Actually, it would be reasonably difficult. If you don't agree why not
spend a weekend implementing it and see how robust your implementation
is? Also, adding object-level locking would involve a huge performance
penalty. 

> All other modern languages are free-threaded. 

Ruby is not free-threaded in the sense that you mean.

> "Therefore, the rule exists that only the thread that has acquired the
> global interpreter lock may operate on Python objects or call Python/C
> API functions. In order to support multi-threaded Python programs, the
> interpreter regularly releases and reacquires the lock -- by default,
> every 100 bytecode instructions (this can be changed with
> sys.setcheckinterval()). The lock is also released and reacquired
around
> potentially blocking I/O operations like reading or writing a file, so
> that other threads can run while the thread that requests the I/O is
> waiting for the I/O operation to complete."
> 
> Yuck. 

You can release the lock at other times too. If you were doing a
long-running calculation that doesn't require use of the Python API, for
example, it would be appropriate to release the GIL.

> Only one global variable left (in fact there is Py_None as well). Why
> not get rid of it, then??

I think that you must be missing something... There is nothing special
about Py_None. The number 5 is globally shared just like Py_None is.
This is a performance optimization used to prevent lots of small numbers
from being allocated and destroyed all the time.

Cheers,
Brian