decorators vs GIL

[Jacob Hallen]

In article <mailman.1464.1092156423.5135.python-list at python.org>,
Skip Montanaro  <skip at pobox.com> wrote:
>
>    Anthony> As far as "fixing" the GIL - well, no-one on Python-Dev has
>    Anthony> obviously found it to be a problem for them. 
>
>I wouldn't state the case that strongly.  There appear to be bigger fish for
>the python-dev gang to fry up to this point.  Perhaps if more of us were
>scientific computation types the GIL would be seen as a more important
>barrier to be removed.  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.
>
>Skip

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.

It is not really reasonable to have 2 different sets of source code
to maintain the 2 versions of the interpreter, but it might be possible
to make an abstraction of the locking that allows the source code
to compile into 2 different interpreters with different locking
strategies.

Practical implementation would probably be a very big project. Especially in
the case of the standard Python implementation.

Jacob Hallén

--