Jython, GILs and object locking.
alanmk at hotmail.com
Wed Oct 22 12:58:14 CEST 2003
>>> 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.
>> 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).
> 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.
check http headers here: http://xhaus.com/headers
email alan: http://xhaus.com/mailto/alan
More information about the Python-list