Martin v. Löwis wrote:
> Nick Coghlan schrieb:
>> I was thinking it would be easier to split out the Global Interpreter Lock
>> and
>> a per-interpreter Local Interpreter Lock, rather than trying to go to a full
>> free-threading model. Anyone sharing other objects between interpreters
>> would
>> still need their own synchronisation mechanism, but something like
>> threading.Queue should suffice for that.
>
> The challenge with that is "global" (i.e. across-interpreter) objects.
> There are several of these: the obvious singletons (None, True, False),
> the non-obvious singletons ((), -2..100 or so), and the extension module
> globals (types, and in particular exceptions).
>
> Do you want them still to be global, or per-interpreter?
The GIL would still exist - the idea would be that most threads would be
spending most of their time holding only their local interpreter lock.
Only when reading or writing the state shared between interpreters would a
thread need to acquire the GIL. Alternatively, the GIL might be able to be
turned into a read/write lock instead of a basic mutex, with threads normally
holding a read lock which they periodically release & reacquire (in case there
are any other threads trying to acquire).
The latter approach would probably give better performance (since you wouldn't
need to be dropping and reacquiring the GIL in order to access the singleton
objects).
Cheers,
Nick.
P.S. Just to be clear, I don't think doing this would be *easy*, but unlike
full free-threading, I think it is at least potentially workable.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
