global interpreter lock not working as it should

Aahz aahz at
Fri Aug 2 02:30:15 CEST 2002

In article <ddc19db7.0208010841.6d45ae01 at>,
Armin Steinhoff <a-steinhoff at> wrote:
>Michael Hudson <mwh at> wrote in message news:<lklm7qgbc6.fsf at>...
>> a-steinhoff at (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

>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(),,
> 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           <*>

Project Vote Smart:

More information about the Python-list mailing list