Jython, GILs and object locking.

[Mikhail Terekhov]

David Bolen <db3l at fitlinxx.com> wrote in message news:<uy8vfv63h.fsf at fitlinxx.com>...
> 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.
> 

In other words you want all global objects to be _implicitly_ thread
safe?
In general it is possible only in a degenerated read only case (no
protection at all). That is why every guide on threading in Python or
in any other language supporting threads or multitasking will tell you
to _explicilly_ use synchronization primitives or high level thread
aware
objects like Queue (or protected objects in Ada for example). The key
word here - explicitly.
It is impossible to 'protected against multi-thread access' in
general.
It is very application specific. The only 'general' thing you can do
is
to provide some kind of synchronization primitives - locks,
semaphores,
monitors etc.

> 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

That looks like a good practice - keep threads loosely coupled and
make
any interactions between them explicit and localized (through Queue
for
example).

> 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.
> 

It looks very similar to what Tcl does with threads.

> 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.

The producer/consumer paradigm (get job description - do the job -
return result) is very common indeed.