[Python-Dev] Making python C-API thread safe (try 2)
Martin v. Löwis
martin at v.loewis.de
Mon Sep 15 23:39:19 CEST 2003
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
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
> 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.
More information about the Python-list