decorators vs GIL

[Donn Cave]

In article <411689bd$0$25588$636a15ce at news.free.fr>,
 Xavier Combelle <xavier_combelle at yahoo.fr> wrote:
> Anthony Baxter wrote:
> >On Sun, 08 Aug 2004 14:57:12 +0200, Xavier Combelle
> ><xavier.combelle at free.fr> wrote:
...
> >Plenty - try this google search:
> >http://www.google.com/search?q=site%3Adocs.python.org+GIL
> >for a couple of simple ones, but there's plenty more - google for
> >"python GIL" (or "python free-threading" for patches that were 
> >written against Python 1.4 to remove the single lock. They ended
> >up slowing down Python significantly.

> That is not really surprizing, the GIL is a very simple and very 
> efficient way to manage
> multithreading. After reading, I can't undersand that other interpreted 
> languages don't do the same.
> The use of GIL make that interpreter work as a single thread process.

Right, and other languages do indeed do the same, for
example I believe ocaml has a global lock - even though
compiled to native code, it has the same kind of shared
global state for storage and so forth.

It is very effective, and it works fine for the kinds
of things people usually do today with threads.  If the
computer of the future makes many processors available
for concurrent processing, it won't work quite so well
for that, but who knows what will happen.

I'm not sure if I followed the rest of your post, but
note that Python's thread architecture works well with
blocking I/O.  It just depends on the native code module
that actually posts the I/O request to release the lock
first, and recover it afterwards, so any other threads
that may be waiting can be scheduled.  On the other hand,
there are often better ways to deal with blocking I/O
than threads.

   Donn Cave, donn at u.washington.edu