Why GIL? (was Re: what's the point of rpython?)

[Aahz]

In article <7xd4ele060.fsf at ruckus.brouhaha.com>,
Paul Rubin  <http://phr.cx@NOSPAM.invalid> wrote:
>alex23 <wuwei23 at gmail.com> writes:
>>
>> Here's an article by Guido talking about the last attempt to remove
>> the GIL and the performance issues that arose:
>> 
>> "I'd welcome a set of patches into Py3k *only if* the performance for
>> a single-threaded program (and for a multi-threaded but I/O-bound
>> program) *does not decrease*."
>
>The performance decrease is an artifact of CPython's rather primitive
>storage management (reference counts in every object).  This is
>pervasive and can't really be removed.  But a new implementation
>(e.g. PyPy) can and should have a real garbage collector that doesn't
>suffer from such effects.

CPython's "primitive" storage management has a lot to do with the
simplicity of interfacing CPython with external libraries.  Any solution
that proposes to get rid of the GIL needs to address that.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote 
programs, then the first woodpecker that came along would destroy civilization.