global interpreter lock not working as it should

[Steve Holden]

"anton wilson" <anton.wilson at camotion.com> wrote in message
news:mailman.1028065844.28617.python-list at python.org...
>
> >
> > [and certainly not by assuming the Python developers are too lazy or
stupid
> > to have thought of this before and demanding some kind of action.]
>
> It would seem that python developers like to assume other people are
calling
> 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
process.

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