global interpreter lock not working as it should

anton wilson anton.wilson at
Fri Aug 2 20:18:25 CEST 2002

> 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.

The only hostility was the above comment about me implyingly name-calling. I 
don't mind the other comments.

> 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 process.

The requirement *was* based on what i had discerned from the documentation. 
Secondly, this post is very old, my mind already changed on this a *long* 
time ago thanks to the great help of Tim Peters.

> 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