global interpreter lock not working as it should

[Aahz]

In article <ddc19db7.0208010841.6d45ae01 at posting.google.com>,
Armin Steinhoff <a-steinhoff at web.de> wrote:
>Michael Hudson <mwh at python.net> wrote in message news:<lklm7qgbc6.fsf at pc150.maths.bris.ac.uk>...
>> a-steinhoff at web.de (Armin Steinhoff) writes:
>>> 
>>> The 'problem' is that Python threads are not fully comparable with
>>> system level threads. Python threads are managed (scheduled) at
>>> _interpreter level_!!
>>> 
>>> The important difference is that Python threads can't use e.g.
>>> blocking I/O calls ... a blocking I/O call used in a Python thread
>>> will block the whole interprete!!.
>> 
>> This is just not true.
>
>Sorry ... your statement is simply wrong.

Do you really believe that after being told by multiple Python experts
that you're wrong?  Sheesh.  The only reason I'm still responding to
this idiocy of yours is to make sure that nobody else makes the same
mistake.

>From the thread docs ... section caveats:
>
>    Not all built-in functions that may block waiting for I/O allow other
>    threads to run. (The most popular ones (time.sleep(), file.read(),
>    select.select()) work as expected.)
>
>Yes ... only the most 'popular' ones are working (because there is only ONE
>system thread (or process) spent for the interpreter)

You're wrong on two counts here (and Martin was actually partially
wrong): the problem is that some functions (such as gethostbyname())
aren't threadsafe, so the GIL isn't released.  That doesn't mean that
each Python thread isn't an OS-level thread.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

Project Vote Smart: http://www.vote-smart.org/