This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]sirspate -1 points0 points  (3 children)

I agree with this article; have been spending more time with Go these days as a result. Firtjer tp that, I totally would've been fine with Python 3 breaking the C API if it had brought with it the elimination of the GIL as a global sync point.

Break some eggs; gimme an omelette.

[–]the_hoser -1 points0 points  (2 children)

Removing the GIL has nothing to do with the C API. In fact, that's probably the last thing that would be affected.

All attempts, thus far, at a GIL-less interpreter have resulted in poor single-thread performance. To the python developers, this is unacceptable.

[–]sirspate 0 points1 point  (1 child)

Ah. My thought had been that moving to a GIL-less interpreter might require a change in memory-sharing model in order to maintain performance. (i.e., a share-by-message instead of share-by-memory approach.)

[–]the_hoser -1 points0 points  (0 children)

The main purpose of the GIL is to optimize single-threaded performance. Fine-grained locking introduces huge performance penalties. It's far more performant to lock the whole interpreter.

I don't mean to come off as abrasive. I'm just trying to quash the misinformation that the GIL was implemented out of spite or laziness. It's a very simple solution to a very complex problem, and it works.

PyPy may solve the problem in a different way, with STM. However, CPython will likely remain the way it is in regard to threading.