global interpreter lock not working as it should

[Armin Steinhoff]

aahz at pythoncraft.com (Aahz) wrote in message news:<aicjqn$hr3$1 at panix1.panix.com>...
> 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?

No ... when I follow up the discussion, it seems to be obviously that
most Python experts are NOT operating system experts!

>  Sheesh.  The only reason I'm still responding to
> this idiocy of yours
> is to make sure that nobody else makes the same mistake.

Sounds a little bit helpless :) You have a bad discussion 'culture'
...
 
> >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,

No ... _Python_ in common _isn't_ threadsafe.

The GIL is used to create a critical section for the byte code
processing of the interpreter, because every interpreter thread
creates its own interpreter instance. These instances are working
concurrently.  (The critical section takes 10 byte codes ... even if
there are critical actions or not, but this number is adjustable and
should be minimized if we talk about real-time behavior)

The documentation is a little bit confusing regarding blocking I/Os.
It makes no sense to use e.g. time.sleep() in a critical section
spawned by the GIL ... this will kill the real-time behavior of the
other interpreter threads.

> so the GIL isn't released.  That doesn't mean that
> each Python thread isn't an OS-level thread.

This doesn't say nothing ...

Oh yes ... I have to correct me: Python threads _are_ system level
threads!!
(Every new interpreter thread does its own evaluation of a Python
object by PyEval_CallObjectWith....)

Cheers

Armin