global interpreter lock not working as it should
anton wilson
anton.wilson at camotion.com
Fri Aug 2 14:18:25 EDT 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 http://www.holdenweb.com/
> Python Web Programming http://pydish.holdenweb.com/pwp/
> -----------------------------------------------------------------------
More information about the Python-list
mailing list