global interpreter lock not working as it should
Martin v. Loewis
martin at v.loewis.de
Thu Aug 1 19:05:49 CEST 2002
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.
> > 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)
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