Jython, GILs and object locking.

Alan Kennedy alanmk at hotmail.com
Wed Oct 22 06:58:14 EDT 2003


[Harri Pesonen]
>>> 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.

[David Bolen]
>> 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). 

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

While I was lying awake last night (kept awake by some spectacular and
unseasonal weather), it occurred to me that using (specially
implemented) Queue.Queue's to communicate between producing/consuming
threads/interpreters, in Harri's proposed model, would solve many of
the problems of object sharing in a natural way.

However, I can't see how it could be done without pickling the objects
for transport across the Queue: the same object cannot exist in both
the sending and receiving interpreters. If it did exist in both, there
would have to be some form of global lock protecting the object
"respository" in which the shared object was stored.

Which means we're back to square one: this scenario would be no
different than using multiple independent python interpreters, running
in different OS processes, bound to different processors, and
communicating through some socket/fifo/pipe type mechanism.

The socket/fifo/pipe mechanism has one big advantage over Queue.Queue:
it can be included in select statements, for non-blocking IO. The
downside is that Queue.Queue's can have multiple producers and
consumers, whereas socket-type channels cannot.

In standard python, it would be great to be able to include
Queue.Queue's in the set of "descriptors" for a select statement,
without requiring multiple threads.

-- 
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan:              http://xhaus.com/mailto/alan




More information about the Python-list mailing list