global interpreter lock not working as it should

Martin v. Loewis martin at
Thu Aug 1 19:05:49 CEST 2002

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.

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

Not true. Python threads *are* system system threads, scheduled by
the operating system. There is *no* scheduling at interpreter level.

Python thread *can* use blocking I/O calls, and doing so *will not*
necessarily block the whole interpreter.

The reason for this statement in the documentation is a completely
different one; this is commonly referred to as "GIL", or "global
interpreter lock" (see the subject of this thread).

So you *are* wrong.


More information about the Python-list mailing list