Jython, GILs and object locking.
David Bolen
db3l at fitlinxx.com
Mon Oct 20 19:31:46 EDT 2003
More information about the Python-list mailing list
Mon Oct 20 19:31:46 EDT 2003
- Previous message (by thread): Jython, GILs and object locking.
- Next message (by thread): Jython, GILs and object locking.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): Jython, GILs and object locking.
- Next message (by thread): Jython, GILs and object locking.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list