global interpreter lock not working as it should

Steve Holden sholden at
Fri Aug 2 19:32:58 CEST 2002

"anton wilson" <anton.wilson at> wrote in message
news:mailman.1028065844.28617.python-list at
> >
> > [and certainly not by assuming the Python developers are too lazy or
> > to have thought of this before and demanding some kind of action.]
> It would seem that python developers like to assume other people are
> them stupid and lazy and take hints as offensive or demanding action. I've
> never seen so much hostility to a bug in my life.
They Python developers are far too used to people implying their laziness
and stupidity to be particularly moved by yet one more possible example.

Firstly, I think you're overreacting if you think the other posters are
responding with hostility. They are simply trying to make their point, with
increasing vigor, that the GIL/threads implementation as currently
implemented is NOT buggy.

Secondly, I think you are being a little rude, or (deliberately?)
obstreperous, in disbelieving what they are telling you. There is simply no
requirement for a CPU-intensive thread to yield to other threads in the same

Consequently there is no reason why other threads should ever get CPU time
until the running cohort thread actually blocks awaiting some external
event. Python, and correctly-coded extensions, are explicitly written to
give up the GIL, and allow other threads to run, at such points.

but-apparently-you'll-continue-to-believe-what-you-want-ly y'rs  - steve
Steve Holden                       
Python Web Programming      

More information about the Python-list mailing list