[Pyrex] pyrex for parrots?

len-l at telus.net len-l at telus.net
Wed May 25 18:51:06 CEST 2005


On 24 May 2005 at 20:10, Michal Wallace wrote:

> On Thu, 19 May 2005, Greg Ewing wrote:
>
[snip]
> > Even without Pyrex, I wouldn't feel confident that
> > complex builtin types such as dictionaries would work
> > correctly in a refcount-disabled environment, since
> > their implementation may be using other Python
> > objects internally.
> 
> 
> Why do you say dangerous? I really know nothing about
> garbage collection, so I could be completely wrong,
> but what's the worst that could happen? A memory leak?
> (Parrot has it's own garbage collection scheme)
> 
>
For a garbage collector to recognize that an object is alive, that object must either 
be directly or indirectly referenced by some special root object or internal pointer 
that by definition is alive. Python extension modules, Pyrex modules included, do 
not provide this anchoring (my term). It is unnecessary with reference counting. 
Pyrex may reference a newly created python object with an ordinary local C pointer. 
A garbage collector would know nothing about this references, so it would assume 
the object  is dead.

Now CPython does have a cyclic garbage collector running in the background to 
remove reference cycles. But this garbage collector is clever enough  to use the 
reference counts to decide if objects are truly dead. Again, no anchoring.

To sum up,  attempting to compile and use a Python extension module with 
garbage collection only would lead to objects being prematurely garbage collected, 
causing all kinds ot confusion.

Lenard Lindstrom
<len-l at telus.net>




More information about the Pyrex mailing list