Re: [Pyobjc-dev] ObjC GC with PyObjC?

[Ronald O. <ron...@ma...>]

On 4 Jun, 2009, at 17:48, Jonathan Saggau wrote:

> Ronald Oussoren wrote:
>>
>> I don't agree. There could be advantages for regular python as  
>> well, IMHO removing CPython's refcounting is a necessary first step  
>> for removing the GIL.  Removing the GIL would definitely be an  
>> advantage for general python code, especially because using  
>> multiple independent threads of execution is the only way to  
>> seriously improve performance on modern hardware because sadly  
>> enough the "wait a year and then my single-threaded code is twice  
>> as fast"-era is over. Multiprocessing is a cool hack, but isn't a  
>> real solution; I have a number of programs that use multiple  
>> threads and need shared memory to get fast enough communications  
>> (basicly because large objects get transferred between threads).
>>
>> Ronald
> As a curiosity for those who know the internals of Python better  
> than I do, is there any reason to believe that most existing python  
> code would even "care" which flavor of GC it's running under?

Sadly enough, yes.  Code like "data = open(filename, 'r').read()" is  
pretty common in small python scripts, and mostly works fine in a  
refcounting python, but doesn't work as well with other GCs because  
the result of open might not be collected until a long time after the  
file is used. That's no problem in general, but is a problem when  
dealing with scarce resources such as file handles.

Such code would already run into problems on Jython, and possibly on  
IronPython as well. When you use a modern version of python the  
correct way to write this isn't much more code:

:>   with open(filename 'r') as fp:
:>       data = fp.read()

In earlier versions of python this would have to be written as:

:>   fp = open(filename, 'r')
:>   try:
:>      data = fp.read()
:>   finally:
:>      fp.close()

Which explains why a lot of people would rely on an implementation  
detail of the garbage collector ;-).

The really interesting questions are if there is code like this in  
major libraries (such as sqlalchemy or twisted), and if there is code  
that relies on really obscure edge-cases that might be hard to  
reproduce with another collector.  In CPython you can revive an object  
in the __del__ of a class. That is:


:>   junk = []
:>   class MyClass:
:>        def __del__(self):
:>            junk.append(self)
:>
:>   a = MyClass()
:>  del a

In this snippet an instance of MyClass is created, and immediately  
after that the only reference to it is removed and CPython tries to  
delete the object. The __del__ method then adds the object to a global  
list, and therefore revives the object.

Code like this cannot work with Apple's GC, that collector requires  
that objects go away when the GC finalizes them.  I sincerely hope  
that no-one actually uses this loophole in production code, it is  
really nasty behaviour.


Ronald