[Python-Dev] Fwd: Removal of GIL through refcounting removal.

[Nick Coghlan]

Maciej Fijalkowski wrote:
>> ...
> 
>> We know it is the plan for PyPy to work in this way, and also that
>> Jython and Ironpython works like that (using the host vm's GC), so it
>> seems to be somehow agreeable with the python semantics (perhaps not
>> really with __del__ but they are not really nice anyway).
>>
> 
> PyPy has a semi-advanced generational moving gc these days. It's not
> as well tuned as JVMs one, but it works quite well. Regarding semantic
> changes, there is a couple which as far as I remember are details
> which you should not rely on anyway (At least some of the below
> applies also for Jython/IronPython):
> 
> * __del__ methods are not called immediately when object is not in a cycle
> 
> * all objects are collected, which means objects in cycles are broken
> in arbitrary order (gc.garbage is always empty), but normal ordering
> is preserved.
> 
> * id's don't always resemble address of object in memory
> 
> * resurrected objects have __del__ called only once in total.

Yep, I'm pretty those are all even explicitly documented as
implementation details of CPython (PEP 343's with statement was largely
added as a cross-implementation way of guaranteeing prompt cleanup of
resources like file handles without relying on CPython's __del__
semantics or writing your own try/finally statements everywhere).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------