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

[Martin v. Löwis]

Harri Pesonen <fuerte at sci.fi> writes:

> 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. So we are in this GIL world just
> because of that old code... 

This statement is not true. It is not trivial, and it is not being not
done because of old code.

Your approach to support "multi-threading" (add an interpreter state
to all functions) would allow to use different interpreters across
different threads, and those interpreters could not share a single
object.

I doubt that this is what most users would want as "SMP Python", and
it has no significant difference over a multi-process solution.

IOW, it is a useless approach.

> It's like Visual Basic 6, it can't multitask properly either (but
> for other reasons). All other modern languages are
> free-threaded. Before I learned Python I assumed that it is as well.

You mean, like Tcl, Perl, or Ruby? Neither of these has free threading
(plus, your proposed implementation strategy would not offer free
threading, either)

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

Because global variables are not the only problem. Not even the most
important one. Atleast not if you want free threading.

Regards,
Martin