Status of Python threading support (GIL removal)?

[Carl Banks]

On Jun 20, 8:18 pm, s... at pobox.com wrote:
>     Carl> Maybe you don't intend to sound like you're saying "shut up and
>     Carl> use C", but to me, that's how you come off.  If you're going to
>     Carl> advise someone to use C, at least try to show some understanding
>     Carl> for their concerns--it would go a long way.
>
> Then you haven't been listening.  This topic comes up over and over and over
> again.  It's a well-known limitation of the implementation.  Poking people
> in the eye with it over and over doesn't help.  The reasons for the
> limitation are explained every time the topic is raised.  In the absence of
> a GIL-less CPython interpreter you are simply going to have to look
> elsewhere for performance improvements I'm afraid.  Yes, I'll drag out the
> same old saws:
>
>     * code hot spots in C or C++
>
>     * use tools like Pyrex, Cython, Psyco or Shed Skin
>
>     * for array procesing, use numpy, preferably on top of a recent enough
>       version of Atlas which does transparent multi-threading under the
>       covers
>
>     * use multiple processes
>
>     * rewrite your code to use more efficient algorithms
>
> I don't write those out of ignorance for your plight.  It's just that if you
> want a faster Python program today you're going to have to look elsewhere
> for your speedups.

Just for the record, I am not taking issue with the advice itself
(except that you forgot "use Jython/IronPython which have no GIL").
I'm not even saying that Python was wrong for having the GIL.

All I'm saying is that [this is not aimed specifically at you] this
advice can be delivered with more respect for the complainer's
problem, and less fanboy-like knee-jerk defensiveness of Python.


Carl Banks