Using python as primary language

[Hrvoje Niksic]

"Martin Vilcans" <martin at librador.com> writes:

>> If by 'this' you mean the global interpreter lock, yes, there are good
>> technical reasons.  All attempts so far to remove it have resulted in an
>> interpeter that is substantially slower on a single processor.
>
> Is there any good technical reason that CPython doesn't use the GIL
> on single CPU systems and other locking mechanisms on multi-CPU
> systems?

It's not the locking mechanism itself that is slow, what's slow is the
Python you get when you remove it.  By removing the GIL you grant
different threads concurrent access to a number of shared resources.
Removing the global lock requires protecting those shared resources
with a large number of smaller locks.  Suddenly each incref and decref
(at the C level) must acquire a lock, every dict operation must be
locked (dicts are used to implement namespaces and in many other
places), every access to a global (module) variable must be locked, a
number of optimizations that involve using global objects must be
removed, and so on.  Each of those changes would slow down Python;
combined, they grind it to a halt.