Jython, GILs and object locking.

[David Bolen]

Harri Pesonen <fuerte at sci.fi> writes:

> Mostly the latter. It would be 99% compatible with the Python syntax,
> the only difference would be in threading. But it would be
> free-threading, not pseudo-threading as the current Python.

I think where I've gotten confused at times in this discussion is that
in my case (and perhaps for many of us judging by the other
responses), discussing a "free-threading" Python implies a Python
where you can write multiple threads of execution using something
equivalent to today's thread/threading modules - all within the same
interpreter - that all have full access to the same set of objects.
That to me is the most interesting long term conceptual model if we
were to really want to adjust changing how the GIL functions.

But doing so requires much finer grained locking since any object in
the system (not just the static objects that you seem focused on)
needs to be protected against multi-thread access.

What you seem to be aiming at is the ability to have multiple Python
interpreters in the same process (but executing in isolation, except
perhaps through limited, special purpose information exchanges).  In
many respects, you'll be taking the typical model proposed by people
suggesting how to get around the GIL (multiple processes with IPC) and
just moving the multiple processes into multiple interpreters within
the same process.

That certainly seems more doable, and as you suggest, the object
locking needs only occur with global, static objects (and/or you just
need to change them to per-interpreter), but at least for me it's also
less interesting as a general solution, since the separate intepreters
are executing in "ships in the night" mode rather than true multiple
threads of execution within the same containing set of resources,
which is where I find threading helpful.

That's not to say it might not be helpful.  While I suspect your
target case of interpreters within a web or other application server
might be the only primary use case, it's a large enough use case that
supporting it is an interesting effort.

-- David