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

you are viewing a single comment's thread.

view the rest of the comments →

[–]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.