Python 3.2 - GIL - good/bad?

Question

Python 3.2 ALPHA is out.

From the Change Log, it appears the GIL has been entirely rewritten.

A few questions:

1. Is having a GIL good or bad? (and wh

Answer 1

Is having a GIL good or bad? (and why).

Neither -- or both. It's necessary for thread synchronization.

Is the new GIL better? If so, how?

Have you run any benchmarks? If not, then perhaps you should (1) run a benchmark, (2) post the benchmark in the question and (3) ask specific questions about the benchmark results.

Discussing the GIL in vague, handwaving ways is largely a waste of time.

Discussing the GIL in the specific context of your benchmark, however, can lead to a solution to your performance problem.

Question though, why does CPython not just clone the interpreter like Perl does in an attempt to remove the need for the GIL?

Read this: http://perldoc.perl.org/perlthrtut.html

First, Perl didn't support threads at all. Older Perl interpreters had a buggy module that didn't work correctly.

Second, the newer Perl interpreter has this feature.

The biggest difference between Perl ithreads and the old 5.005 style threading, or for that matter, to most other threading systems out there, is that by default, no data is shared. When a new Perl thread is created, all the data associated with the current thread is copied to the new thread, and is subsequently private to that new thread!

Since the Perl (only specific data is shared) model is different from Python's (all data is shared) model, copying the Perl interpreter would fundamentally break Python's threads. The Perl thread model is fundamentally different.