decorators vs GIL

[Aahz]

In article <Pine.LNX.4.44.0408101504070.9982-100000 at ccc2.wpi.edu>,
Christopher T King  <squirrel at WPI.EDU> wrote:
>
>The real reason behind the GIL is that the Python interpreter is not
>re-entrant; it keeps internal state in a global structure which must be
>switched out (and stored somewhere) on thread changes.  The real solution
>to this problem is to make the interpreter stateless, thus obviating the
>need for the GIL entirely.  I think this task would be much easier to do
>in Stackless than in CPython, but I may be wrong.

There's no "the" real reason.  Another critical reason is that it's a
design goal of CPython to be a useful glue language for C libraries.
Many libraries use internal static variables....

Until a good API exists on all standard platforms for determining
whether a library call needs a GIL around it, we can't seriously discuss
removing the GIL.  Currently, any library designed to work with Python's
GIL can easily unlock the GIL while it's running "standalone" (no calls
back into Python).
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"To me vi is Zen.  To use vi is to practice zen.  Every command is a
koan.  Profound to the user, unintelligible to the uninitiated.  You
discover truth everytime you use it."  --reddy at lion.austin.ibm.com