Jython, GILs and object locking.

[Harri Pesonen]

David Bolen wrote:
> 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.

Thanks for the message. It sums up the idea quite well. Also I can 
imagine the following syntax for objects that *are* shared between 
different threads:

shared a = "asdf"

Or as the "global" discussion suggested:

shared.a = "asdf"

Access to these shared objects would always be synchronized, but only to 
these. And if you assign to shared objects, you always make a copy of 
the original object (if it was a thread-local object), and vice versa. 
This way different threads could access the shared memory almost as 
elegantly as the current Python.

Harri