decorators vs GIL

[Christopher T King]

On 10 Aug 2004, Jacob Hallen wrote:

> >That a fairly bright guy (Greg Stein) removed it once and found
> >performance to be disappointing doesn't advocate strongly for removal
> >of the GIL either.
> 
> So, what we really want to do is to remove the GIL, and keep it.
> 
> Ignoring trivialities like practical implementation, we can do this, since
> the moment we start running our program, we will be able to find out
> if we are running in an environment were we have access to multiple
> processors (and if the program has the ability to use them (at least most
> of the time)). If we can use multi-processing, we invoke a Python
> interpreter with fine grained locking, otherwise we stick with the
> GIL.

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.