threading.py -> winthreading.c : Some results
Paul Rubin
phr-n2002a at nightsong.com
Wed Jan 2 00:24:44 EST 2002
More information about the Python-list mailing list
Wed Jan 2 00:24:44 EST 2002
- Previous message (by thread): Python-cgi Web Cobrowsing app
- Next message (by thread): threading.py -> winthreading.c : Some results
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
"Tim Peters" <tim.one at home.com> writes: > However, Python's internal uses of locks-- and particularly the GIL --don't > need these unusual (relative to what platforms usually offer in the way of > native synch gimmicks) semantics. The GIL is "owned": a thread T that > acquires the GIL won't try to acquire it again while it's acquired, T will > eventually release it itself, and no other thread will attempt to release it > while T has it held. Most platforms have a more efficient synch > implementation for this simple usage, but we never got around to creating an > internal lock type to exploit this. Just about *any* mutex gimmick would > suffice except for a spin lock (the GIL can be held by a thread for an > arbitrarily long time): the GIL exists solely to enforce serialization. Is it feasible to replace the GIL with something else, that allows Python programs to use the parallelism on multi-cpu systems?
- Previous message (by thread): Python-cgi Web Cobrowsing app
- Next message (by thread): threading.py -> winthreading.c : Some results
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list