Status of Python threading support (GIL removal)?

[Carl Banks]

On Jun 19, 11:08 am, OdarR <Olivier.Da... at gmail.com> wrote:
> On 19 juin, 19:13, s... at pobox.com wrote:
>
> >     Olivier> what do you mean ?
>
> >     Olivier> Cpython can't benefit from multi-core without multiple
> >     Olivier> processes.
>
> > It can, precisely as Martin indicated.  Only one thread at a time can hold
> > the GIL.  That doesn't mean that multiple threads can't execute.  Suppose
>
> I don't say multiple threads can't execute....(?).
> I say that with the Python library, I don't see (yet) benefit with
> multiple threads *on* multiple CPU/core.


He's saying that if your code involves extensions written in C that
release the GIL, the C thread can run on a different core than the
Python-thread at the same time.  The GIL is only required for Python
code, and C code that uses the Python API.  C code that spends a big
hunk of time not using any Python API (like, as Skip pointed out, a
matrix multiply) can release the GIL and the thread can run on a
different core at the same time.

I always found to be a *terribly* weak rationalization.  The fact is,
few Python developers can take much advantage of this.

(Note: I'm not talking about releasing the GIL for I/O operations,
it's not the same thing.  I'm talking about the ability to run
computations on multiple cores at the same time, not to block in 50
threads at the same time.  Multiple cores aren't going to help that
much in the latter case.)

I wish Pythonistas would be more willing to acknowledge the (few)
drawbacks of the language (or implementation, in this case) instead of
all this rationalization.  It's like people here in Los Angeles who
complain about overcast days.  What, 330 days of sunshine not enough?
Jesus.  I wish people would just say, "This is a limitation of
CPython.  There are reasons why it's there, and it helps some people,
but unfortunately it has drawbacks for others", instead of the typical
"all u hav 2 do is rite it in C LOL".


Carl Banks